Open Stack

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|