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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
