HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

The road to the next major release (2.2)

12346

Comments

  • hgtonighthgtonight ∞ · New Moderator

    @Adrian said:
    Canadians actually use onboarding too

    Americans use water-boarding

    Oh wait...

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • chanhchanh OngETC.com - CMS Researcher ✭✭

    Some circle use "acclimating"

  • acclimating wth? acclimatising or acclimatizing if you must.

    That is like people who use of the word 'utilize' all the time when 'use' is adequate.

    grep is your friend.

  • x00x00 MVP
    edited May 2015

    I have misunderestimated your strategery of utilising acclimating with young internpersons. I gather onboarding was only partially successful, with one left on the pier and the other been thrown a lifebuoy.

    grep is your friend.

  • Yeah, "onboarding" is a great word. Now, please please please release.

  • R_JR_J Ex-Fanboy Munich Admin

    @xDaizu: you should star the GitHub repository so that you get the notifications of what is going on there. That's really insightful!

  • BleistivtBleistivt Moderator

    @xDaizu It's not like they are keeping it secret. Nothing stops you from just installing master from github. Just try it out locally first.

  • @Bleistivt I do, and every week I install the new master version and it breaks my plugins and I have to redo everything :skull: . I need a "stable point" to work from. That's why I am so impatient! :confounded:

    And no, I can't use 2.1 since some plugins I need, like the API plugin doesn't work in 2.1.

    I know that asking for it once and again won't probably accelerate the process, and my intention is not to push you. I just want to communicate my vision as a newcomer, which is that 2.2 really needs to be released ASAV (as soon as viable), because as per now, Vanilla is in a very unstable place, with the 2.2 tags being way older than the 2.1 and deprecated; important plugins requiring 2.2+ and the current 2.2 (master branch) changing in a big way (or small but breaking stuff) every week. As a newcoming developer this is a really unfriendly environment to develop a REALLY big application around it, but, for some reason, I REALLY want to use Vanilla in my project.

  • hgtonighthgtonight ∞ · New Moderator

    @x00 said:
    acclimating wth? acclimatising or acclimatizing if you must.

    That is like people who use of the word 'utilize' all the time when 'use' is adequate.

    Never use a large word when a diminutive one would suffice.

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • @hgtonight said:
    Never use a large word when a diminutive one would suffice.

    burglarize vs. burgle ;)

    gotten vs. got

    1:2

    grep is your friend.

  • phreakphreak Vanilla*APP (White Label) & Vanilla*Skins Shop MVP

    @xDaizu: Wow, sounds like a love letter. :) Big application? Let us know.

    • VanillaAPP | iOS & Android App for Vanilla - White label app for Vanilla Forums OS
    • VanillaSkins | Plugins, Themes, Graphics and Custom Development for Vanilla
  • @phreak said:
    xDaizu: Wow, sounds like a love letter. :) Big application? Let us know.

    At least, pi times better than a hate later! :wink:

    Oh, you'll know. Eventually. Or at the very least, you'll see some plugins and themes coming as soon as we can start developing. (Well... actually a few weeks later, because, you know, development time...)

  • @hgtonight said:
    Never use a large word when a diminutive one would suffice.

    But long obscure words makes you seem more clev...intellig... sagacious!

  • LincLinc Detroit Admin

    @fienen good points well stated. I'm really hoping that the 2.2 release will put us in a position for open source & staff to work together a great deal more since our code bases will be back in sync for the first time in 4+ years. The 2.1 boondoggle of a release schedule really messed up a lot of the cross-benefits. 2.2 should also be the last long (years) gestation period for a release.

    Speaking of which. These coding standards changes are now the last thing on my blockers list. We've fixed the spacing & inline doc formatting, now we're down to capitalization. This is import to finish before the fork so that we can backport fixes easily to 2.2 as needed without big merge conflicts.

  • @Linc said:
    fienen good points well stated. I'm really hoping that the 2.2 release will put us in a position for open source & staff to work together a great deal more since our code bases will be back in sync for the first time in 4+ years. The 2.1 boondoggle of a release schedule really messed up a lot of the cross-benefits. 2.2 should also be the last long (years) gestation period for a release.

    What does this mean in practice? Does it mean that you are going to make 2.2 as best as can be before moving on to the next incarnation?

    The reason I have asked is there has been great progress with fixes. Just some of them were fixed in a different stream, or far in the future. So didn't make necessarily it into updates.

    I flavour smaller incremental releases for sure. You only have the resource an manpower you have, though you do get to choose what you prioritise on.

    There is something to said for taking a leaf out of phpBB's book, giving a higher priority (and turnaround) to stability, over new features an major architectural changes. This doesn't mean you don't revamp the the framework at all.

    I think there is feel good factor with more releases, with more fixes, over new features any day. You already have a way of categorising issues. I think certain issues, that seem non-critical, but day to day stuff, are the sorts of thing that should get a priority over new features, or major architectural changes.

    Obviously these fixes still have to go through review process so they don't get released right away. But as you said you want to move away from massive code releases, to more incremental.

    There are always going be gripes that people have, you can't stop that. In my book if you have more uncommon gripes than common gripes especially with intended features you are doing well.

    grep is your friend.

  • LincLinc Detroit Admin
    edited June 2015

    @x00 said:
    What does this mean in practice? Does it mean that you are going to make 2.2 as best as can be before moving on to the next incarnation?

    2.2 is going to fork as soon as our standards changes are done (less than a week, I hope). I'd like to see 2.3 6-12 months later. That could change depending on our priorities during that time.

    Just some of them were fixed in a different stream, or far in the future. So didn't make necessarily it into updates.

    A big factor in whether fixes make it into an incremental update is how close the open source version is to the one it got fixed in. My narrowing the time between releases (from years to months) we'll have a lot more flexibility in what can be backported with limited time.

  • @Linc said:
    A big factor in whether fixes make it into an incremental update is how close the open source version is to the one it got fixed in. My narrowing the time between releases (from years to months) we'll have a lot more flexibility in what can be backported with limited time.

    Yep, there should be some rule of thumb especially if the problem is existent in the stable branch, that it is fixed in that branch or major version.

    grep is your friend.

  • LincLinc Detroit Admin

    @x00 said:
    Yep, there should be some rule of thumb especially if the problem is existent in the stable branch, that it is fixed in that branch or major version.

    I think a general guideline is that fixes for issues that are regularly noticeable in day-to-day usage of the software are good candidates for backport (and, of course, security issues). I definitely don't want to get into a scenario where we backport stuff every day. Better to do the next version sooner if there are that many fixes.

  • Sure that's good. and if you are releasing more often anyway it shouldn't be as big a problem

    grep is your friend.

Sign In or Register to comment.