Blog Documentation Book a Demo
Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Your thoughts on Vanilla Release Frequency

TimTim Vanilla Staff
edited January 2011 in Vanilla 2.0 - 2.8
Hi guys,

I'm writing this post in order to learn more about how you guys perceive our releases, our release schedule, and how we might be able to do things better in the future.

You may have noticed that we've recently changed to a 4 point version system. We think that this will allow us to be more disciplined with what we put into our master branch, and more importantly, when we put it there. We plan to make releases like 2.0.17.1, .2, .3 etc contain bug fixes and changes specific to things we did in the 2.0.17 primary release. This means that if you have 2.0.17 and update to 2.0.17.3, you can feel confident that you're only getting fixes, not new features.

Here's what I want to know. What do you guys think of our release frequency? Since 2.0.17 was released, we've done 3 minor pushes (and version increments) to correct bugs we thought were pretty significant. Do you prefer to get up-to-the-minute fixes often, like we've done over the last couple of days, or would you prefer to deal with bugs for a week or so and then get the fixes all at once, or in chunks. If you have a preference here, could you justify it with reasons?

Before you get to answering my questions, I'd like to make a few things clear about what I *don't* want to see in this thread. Forgive me :)

Unrelated feature requests. This isn't a thread where I expect to see you requesting anonymous guest posting, or whatever feature you feel we should be working on. Stay on topic or I'll have to get happy with the delete button.

Bug reports. We have GitHub and other threads for that. Please don't clutter this one!

Automatic updates. This feature, as we've already confirmed, is scheduled for v2.1 and that has not changed. Internal priorities changed slightly over Christmas which has delayed that project slightly, but it is nearly complete and will be here soon.

Finally, please remember that even if you make a very good point here, it doesn't mean your idea is going to make it into our very next release. Sorry :( There are 'good ideas' I've had for months that I have yet to find the time to even start, let alone complete and push. But I'd still like to hear what you guys have to say.

Thanks in advance for your comments!

Vanilla Forums COO [GitHub, Twitter, About.me]

Tagged:

Comments

  • chuckDchuckD
    Minor and slight layout defects can hold/grouped together while annoying (such as google sign in bug) and security type bug fixes need to be pushed out. I would like to suggest that fixes are announced to the community so we can help test in our own configuration to make sure it works before it gets released to everyone.
  • jbhewittjbhewitt
    I think it's a good versioning system letting users know the difference between a bug update and a feature update.

    My only request is to have some type of way informing people to update. Sometimes the updates get washed away in the twitter updates.
  • TimTim Vanilla Staff
    My only request is to have some type of way informing people to update. Sometimes the updates get washed away in the twitter updates.
    http://www.vanillaforums.org/addon/vanilla-core/follow.rss

    Vanilla Forums COO [GitHub, Twitter, About.me]

  • scythahscythah
    I think it's a good versioning system letting users know the difference between a bug update and a feature update.

    My only request is to have some type of way informing people to update. Sometimes the updates get washed away in the twitter updates.
    Agreed. Even if the automatic updates have been pushed back I suggest a message or notification shown to administrators either in the dashboard or (preferably) at the top of the forum (more visible) telling them to do a manual update.

    Also, hello JB.
  • cdavidcdavid New
    How about a public beta of 1 week in which users can test the release (alongside with the devel team) after which the release becomes official? Though, not making it an official release (just a beta) will reduce the number of people willing to download and put it in "live" systems. Maybe a Release Candidate is a better term for this type release?

    Also, this would be reflected nicely in categorizing the official vanillaforums.org forum (which for me now seems to be a little crowded) in (for example):
    -> Current Release
    -> Beta Release
    * 2.0.17
    * 2.0.16
    * ...
    -> Older Release
    * 2.0.16
    * 2.0.15
    -> Plugins
    -> Applications

    And as soon as a new release comes out, move the discussions related to that release to the sub-category in the older release category.

    /cd
  • UnderDogUnderDog MVP
    I also think it's a good versioning system.
    My only request is to have some type of way informing people to update. Sometimes the updates get washed away in the twitter updates.
    I know a system that shows in their control panel whether you have the latest version. It basically reads a text file on the website that always contains the latest version number. If version number on localhost is lower than version number in the text file it shows a message.

    There was an error rendering this rich post.

  • SS ✭✭
    edited January 2011
    Now I'm using... I do not know how to call it but I'll try to explain how I give version number of my programs.
    3 point system: A.B.C
    C = is a build count (revision?), this number increases by 1 (or maybe up to 3 depends on how much change was) always with each release of the program.
    B = actually, release version. Increases with new features, removed deprecated things, real CRITICAL fixes, behavior change, major change of the algorithm of work of the program, etc.
    A = almost always constant, сhanging this number means that programm COMPLETELY REWRITTEN (new algorithms, lost compatibility with older versions, change language programming language, etc.) B.C - resetting.

    Example releaseflow: 
    first release: 1.0.0		[C++]
    small fixes: 1.0.1			[C++]
    small fixes: 1.0.2			[C++]
    new cool feature: 1.1.3		[B++, C++]
    small fixes: 1.1.4			[C++]
    X removed/unsupported: 1.2.5	[B++, C++]
    a big pack of fixes: 1.2.7		[C+=2]
    small fixes: 1.2.8			[C++]
    completely rewritten: 2.0.0	[A++]
    ... here's how it is so
    No restriction on the number of A, B, C (means 2.9.x goes to 2.10.y, not 3.0.y)
    Like apache [2.12.27] example.
  • RajioRajio ✭
    I like the update frequency. It saves me from waiting for minor fixes but I also don't feel obliged to upgrade with every increment lest I miss out on new functionality. You guys do a good job of making it clear what the differences are between versions. Some things, like removing the mac_os folder I don't think require a new version though :P

    A roadmap for upcoming versions would be nice though. So I'd know if a bug fix is in the works or what feaures are planned. This can reduce worry and posts.

    Also I didn't know automatic updates was announced as planned. I'm excited.
Sign In or Register to comment.