On 05/24/2012 10:45 AM, David Nalley 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
* 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.
I have no strong preference, but using the agreed upon points w.r.t.
version numbering as a guideline I would say that the first Apache
release qualifies as a "major event" and thus X should increase.
Therefore, we should have 4.0.0
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
Correct, but also consider that because of the rapid release cycle,
distributions always lag "far" behind the "latest and greatest", or
carry many patches in their package, and that the version available from
distributions for svn is quite different. Not a very nice situation IMHO.
(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.
I personally would lean to the slower end of things, thus my vote is for
a 4 month cycle.
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.
Well, there is not really a "guarantee" for bug fixes, thus I would more
characterize it as a "chance for" or "best effort promise of" bug fixes.
In any event I would tie this to the length of the agreed upon release
cycle. Personally I think we should not expect/force admins of cloud
setups to upgrade more often than once per year maybe even less frequent.
With a 4 month release cycle and a 12 month "support" period, 5.2.0
would get community support until 5.5.0, 6.0.0, 6.1.0, 6.2.0, 7.0.0, or
7.1.0 is released according to the following table:
5.2.0 (includes bug fixes, i.e. 5.2.x)
4 month 8 month 12 month
5.3.0 5.4.0 5.5.0
5.3.0 5.4.0 6.0.0
5.3.0 6.0.0 6.1.0
6.0.0 6.1.0 6.2.0
5.3.0 6.0.0 7.0.0
6.0.0 7.0.0 7.1.0
where each entry in the table is a potential version number depending on
the qualifying event as agreed upon for the X.Y.Z scheme. Yes, this is
very unwieldy, thus I would propose that the length of "support" is time
based rather than version dependent.
We could say that bugs in a given release branch will no longer be fixed
12 month after the release of the X.Y.0 version.
What this means is that even if 5.2.9 is released in month 11 after the
5.2.0 release there is no "support" for 5.2.9 past the 12 month release
anniversary of 5.2.0.
We can now argue about whether this should be 12, 15, 18 month or other ;)
My $0.02
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
