On Thu, Aug 18, 2011 at 3:46 PM, Jonathan Underwood jonathan.underwood@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.