I just reread this, and it sounds more like we decide what the version will be (major or minor) AFTER we know what's going into it. I'm OK with that of course, but we'll need some sort of definition to go by. I also think it may end up in favor of major revs more often than not.
We could also do something else like align major revs with target platforms, e.g. 4.0 targets centos 6.x and Ubuntu 12.04, with minor revs being feature releases. That may help solidify the support life cycle as well, and we just rev when the next generation of platforms is chosen and tested. On Oct 31, 2012 7:02 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > +1, this would line up nicely with having a major rev once a year with 2 > or 3 minor revisions in between. > Then maybe once a month someone rolls up any applicable bugfixes and we do > a point release? Do we want to have some procedure around that, like a mini > vote? > On Oct 31, 2012 6:26 PM, "Chip Childers" <chip.child...@sungard.com> > wrote: > >> 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 >> > >> >
