Open Stack

Daniel P. Berrange wrote:
> On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote:
>> 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.
>>
>> [...]
> 
> 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'.

I guess the main difference is that we would still "release" something
(i.e. generate, version, publish and archive a tarball) in case of D,
which makes it easier to reuse a known point. It would also exhibit
version numbers more visibly, which makes referencing them slightly
easier (currently you have to look into the generated, transient
$PROJECT-stable-$SERIES.tar.gz tarball to see that version number).

-- 
Thierry Carrez (ttx)