Open Stack

Daniel P. Berrange wrote:
> On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote:
>> So.. summarizing the various options again:
>>
>> Plan A
>> Just drop stable point releases.
>> (-) No more release notes
>> (-) Lack of reference points to compare installations
>>
>> Plan B
>> Push date-based tags across supported projects from time to time.
>> (-) Encourages to continue using same version across the board
>> (-) Almost as much work as making proper releases
>>
>> Plan C
>> Let projects randomly tag point releases whenever
>> (-) Still a bit costly in terms of herding cats
>>
>> Plan D
>> Drop stable point releases, publish per-commit tarballs
>> (-) Requires some infra changes, takes some storage space
>>
>> Plans B, C and D also require some release note / changelog generation
>> from data maintained *within* the repository.
>>
>> Personally I think the objections raised against plan A are valid. I
>> like plan D, since it's more like releasing every commit than "not
>> releasing anymore". I think it's the most honest trade-off. I could go
>> with plan C, but I think it's added work for no additional value to the
>> user.
>
> I don't see a whole lot of difference between plan A and D.
> Publishing per-commit tarballs is merely saving the downstream
> users the need to run a 'git archive' command, and providing
> some auto-generated changelog that's already available from
> 'git log'.
>
> If the downsteam consumer has their own extra patches ontop of the
> stable branch, then it seems D is even less useful than A.

+1 to this, and I'm 99% sure every big/medium/all(?) cloud has extra 
patches on-top of stable branches; so publishing a tarball, meh, it will 
have to be regenerated anyway (with said patches) from the git commit it 
came from...

>
> Regards,
> Daniel