On Fri, Aug 19, 2011 at 2:29 PM, James Cammarata <jimi(a)sngx.net> wrote:
It's funny you should mention this, as I've been considering proposing
a more rigid and reliable release schedule. My thought was to create a
6 month release cycle between major versions, with periodic 2.x.y
releases for bug fixes in between. All new features would go in major
releases only, to start creating a more stable environment than we've
had at times in the past (I'm as much to blame for that as anyone).
And by major versions, I do mean in the kernel sense - 2.1, 2.2, etc.
and not 3.x, 4.x... I don't feel any major need to bump the version
number up to 3 yet, unless we do some major, MAJOR changes. How far
back we officially support is up for debate, but I think supporting 2
versions a la fedora is a good starting point - that would give any
version a 1 year life cycle. If we're losing Satellite/Spacewalk, it
will make things easier to maintain at least.
That sounds good.
I'd like to point out that communicating with the userbase via the
wiki/trac is pretty much essential. E.g. using Trac for defining the
milestones/releases and such. As a user i'd like to see what features
will get into a specific release and which bugfixes get backported.
I've seen Scott refer to his TODO list which, for me, isn't quite a
transparent process....
I think the release of 2.1 would be a good starting point for that,
so
we'd have a March/September major release scheduled, which should
allow us to avoid delays because of holidays, etc.
Thoughts?
I think there should be a list of features we absolutely want in 2.1.
When will the feature freeze be? When will the (beta) testing start, etc etc?
Basically, some form of release engineering...
The major feature change I'd like to see for 2.2 would be a new
templating engine. Cheetah has got to go, it is poorly supported and
extremely difficult to debug errors with. We could continue to support
cheetah for a while, but we need to setup some transition plan.
Do you have an alternative in mind?
Grtz,
Jörgen Maas