http://bugzilla.gdcproject.org/show_bug.cgi?id=181
Johannes Pfau <johannesp...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |johannesp...@gmail.com
--- Comment #3 from Johannes Pfau <johannesp...@gmail.com> ---
@Iain Until now I always tagged the last commit on a frontend version. I.e.
v2.065_gcc4.9 is the last commit with 2.065, the next commit is on 2.066.
Of course this means the tags are always one release old. This is annoying for
packagers like Dicebot but it is useful if you want a specific frontend
version. This way the tag always gives the most recent ('best') commit for a
frontend version.
What does the git etiquette say about updating tags? Is it OK to update tags? I
think a standard fetch does not update tags so that's a drawback. And there's
probably not much benefit in using tags for packagers if we update them.
It's also hard to say when a commit qualifies for a tag. Except for the
first&last commit with a frontend version there's nothing special about any
commit. Why tag on "Implement Exception/Error chaining in unwind EH routines"
and not on "Bug 179 - Invalid code generation with -O2 for method returning
ref"? And as our tag is now on "Implement Exception/Error chaining in unwind EH
routines" does this mean that further update Archlinux packages do not pickup
updates till we have a 2.067 tag? What if somebody creates 2.065 packages
later. When he uses the tag he might miss further bugfix commits.
We could introduce arbitrary -snapshotN commits every now and then, but then
those are not very useful:
As our development model doesn't converge to a finished, stable
commit(/release) it's really hard to decide when we should tag. We're more or
less using a 'rolling release' development model.
--
You are receiving this mail because:
You are watching all bug changes.
