On Thu, Aug 18, 2011 at 3:46 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
Hi,
I've noticed that there's been a lot of code added to the trunk in the
past months, and was wondering if there's any roadmap or defined
criteria for cutting a new release?
Cheers,
Jonathan.
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.
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?
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.