On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Definitely. And well said.
<aside>
Havoc Pennington's original proposal for GNOME to adopt time-based releases is still worth a read:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Funnily enough, this was written not long after the Agile Manifesto, but I don't think it was influenced by Agile. Reading it now, though, you can see a lot of overlap with Agile Principles - e.g. it's all about "continuous delivery of valuable software".
</aside>
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
Just call it 0.4.0 IMHO.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Mark,
Awesome reminder that we aren't exactly treading new ground here. Great find!
A number of us really like the time-based release approach but I suspect we've not done a really good job at building consensus within the community around using a time based approach.
On version number, I fear that I led Steve astray in an earlier conversation and agree something 0.4.0ish is the right thing and that we ought to reserve 0.3.1 for maintenance release purposes.
With regards to rpm versioning, we could consider keeping the git hash in the rpm release for the milestone builds. I don't have super strong reasons to keep it other than the fact that it means we don't have to worry about incrementing the spec quite so frequently.
Thanks, Mike