+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
> >
>

Reply via email to