On 07/07/2010, at 15:18, Juan J. Martínez wrote: > El mié, 07-07-2010 a las 15:04 +0200, JR escribió: >> [...] >> My proposal: >> - development with one version who is the "stable" version -> and this >> version ist only modified for fixes >> - another development version who is the "new features and other >> modifications" version > > I agree with that. > > I remember this topic was discarded in the summit, but in cases like > this (the SSL problem it's pretty critic), I think that current release > scheme has some limitations.
I does, indeed. I do not like the idea of maintaing two branches though. It'd have quite an impact in the development speed, affecting both bug fixing and new features development. Instead, I'd go for a tagging mechanism where releases are marked as 'stable' or 'development'. A stable version would ship bug fixes and documentation improvements, while development versions would have added new features. Every single version would come from trunk, independently or whether it is a 'stable' or 'development' release. For instance, the following timeline would be possible according with this scheme: 1.0.6 [devel] 1.0.7 [devel] 1.0.8 [stable] 1.0.9 [stable] 1.0.10 [devel] 1.0.11 [stable] > What do you think? Would it be possible/good review current release > policy? Sure. I just want to make certain that the potential changes are for better. -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
