On Thu, May 24, 2012 at 10:45 AM, David Nalley <da...@gnsa.us> wrote: > So I think we have consensus around a few things already - lets > highlight those: > > * Time based releases > * Versioning scheme: > X.Y.Z > > - X : increases when there is a "major" change in architecture or some > major new feature > - Y : increases with every release every 6 month (reset when X increases) > - Z : increases when there are "must fix bugs" or annoying bugs that > get fixed in a release branch (reset when Y increases) > > > ===== What we don't yet have consensus on ===== > > * What the time period is on releases
Digging this out of the past, IIRC, we never got around to resolving the time period for releases. We should come to a conclusion on this topic! I'd like to propose that we follow a 4 month release cycle for non-bug fix releases. Generally, it would mean a schedule that would look something like this (M=Month and W=Week): M1 through M2 - Features are being developed in branches, and merged into master over the course of these two months M2 W4 - Feature freeze (and release branch is cut). M3 W1 through M4 W1 - Doc Updates and Testing M4 W1 - Docs Freeze M4 W2 - Final regression testing / bug fixes / doc fixes M4 W3 - First RC cut and opened for voting... Wash rince repeat until an RC is voted to be released This proposal might lean a bit heavily towards documentation and testing, but my opinion is that features are going to be developed outside of this release cycle. What matters, is when they land in master, and when they are scheduled to be released. IMO, this type of schedule provides us with the ability to have predictable periods of time for stabilization and documentation. If the actual time period of the release is something other than 4 months, then I would argue for a similar schedule in the ramp up to the first RC. If we can reach a consensus on this, I'll be happy to draft up a schedule with specific dates for our 4.1.0 release. Thoughts, comments, flames? -chip > * What the version number for the first Apache release should be (to > be fair we haven't really discussed this.) > > So lets start with the easy one, the version number - should we target > 3.1.0 or 4.0.0 or something else entirely? I could be swayed either > way. > > On the release time period - as a packager for 20-30 packages in > Fedora I am certainly sympathetic to release cycles, and realize that > virtually all of the community distros (save Debian which is on a two > year release cycle) are on a 6 month cycle. That said I don't know > that we can necessarily be married to what the distros are doing. I > also look at projects like subversion which are tossing out releases > approximately every 60 days - and I don't see any distro that doesn't > carry subversion (though admittedly very different projects in > virtually every respect) I think every 3-4 months makes sense to me, > but again that's just me - gives us a slightly faster iteration but > hopefully not removing towards an unmanageable release cycle speed. > > Another question is - how long do we support any given release > line......e.g. if I embark on 5.2.0 (completely made up version > number, but assuming the above version scheme) how long will I be > guaranteed bugfixes for 5.2.x. Perhaps it's too soon to even ask that > question - we haven't even pushed a single release out, but something > to think about. > > Thoughts, comments, flames? > > --David >
