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
>> 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
>> on *this* date", and then just stick to it.
> Definitely. And well said.
> Havoc Pennington's original proposal for GNOME to adopt time-based
> releases is still worth a read:
> 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".
>> 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.
> aeolus-devel mailing list
Awesome reminder that we aren't exactly treading new ground here. Great
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.
aeolus-devel mailing list
At this point with the ongoing issues around bundler it's not clear to me that we are
stable enough to cut a release. Based on conversations with jayg iiuc install is only
working some of the time.
I am adding a 0.4.x branch to conductor git repo at current tip of master, but I'm not
confident we're ready to tag that as an 0.4.0 release.