On 19 August 2011 13:29, 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.
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?
This seems very reasonable. My main worry was seeing trunk get so much
churn without a release planned - that's a good way to destabilize and
break lots, as not many folks test the trunk.
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.
Also seems reasonable, but the transition might be a bit painful.
Would need a clear plan.
_________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel