http://bugzilla.gdcproject.org/show_bug.cgi?id=181

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Added some lightweight tags for teh recent GCC-5.1 release.

Might be worth periodically (bi-monthly?) checking for bumps to newer
revisions.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #2 from Dicebot <public@dicebot.lv> ---
Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau@gmail.com

--- Comment #3 from Johannes Pfau <johannespfau@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.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #4 from Dicebot <public@dicebot.lv> ---
Common approach is to have extra level of minor versions that "extends" the upstream (gcc in this case) and do smaller releases with those version bumps time to time.

Changing tags is very bad. The very reason why I am asking for tags (as opposed to using branch heads) is to guarantee that same package script built 1 year later will result in exactly same thing packaged. It is also possible to pin to specific commit hashes of course but that will result in inconsistent functionality among distros as everyone will chose own arbitrary commit to stick to.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #5 from Johannes Pfau <johannespfau@gmail.com> ---
That's more or less what I thought. But there's no guiding principle when to make those minor version bumps. In the end we could bump with every commit, every second commit, every week, .... It's completely arbitrary.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #6 from Dicebot <public@dicebot.lv> ---
It is completely up to you. It is simply way to tell packager "prefer this commit" and "consider upgrading gdc". I think two most important cases are frontend version bumps and branch freezes.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #7 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Perhaps we better make the next commit "upgrade to 2.067.1" then. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #8 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Kick-started "the big overhaul".

https://github.com/D-Programming-GDC/GDC/pull/99

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #9 from Dicebot <public@dicebot.lv> ---
There does not seem to be a tag for 5.1 gcc + 2.066 gdc :)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=181

--- Comment #10 from Johannes Pfau <johannespfau@gmail.com> ---
@Dicebot I've added the tag. Thanks for reporting.

-- 
You are receiving this mail because:
You are watching all bug changes.