Tag 3.2rc1

[ryandesign]

distcc 3.2rc1 was released on Google Code in 2011, but the latest tag in this github repository is version 3.1 from 2008. Can you please tag 3.2rc1 here in this repository, and upload the corresponding tarball here using the github releases service? Thanks.

[thinrope]

Looks like this is not possible... I tried to compare quite a few revisions circa 2011-10 from this repo to the released tarball (from googlecode), but I couldn't find a good match.
Code-wise, it would be commit 1dc8c00 but the doc and contrib directories differ, as well as it is missing a configure and config.h.in files (present in the tarball)

So, I'd rather see a new release based on this repo, since that looks like the official one. There is one more repo that kept the subversion references https://github.com/svn2github/distcc may be a good idea to consult.

[afbjorklund]

@thinrope: those files are generated on release (see make dist), so 1dc8c00 is indeed the v3.2rc1.

[thinrope]

OK, then I'd suggest to run make dist && git commit -a -m "Releasing _WHATEVER_" && git push and tag that as a release in the future.

[afbjorklund]

@thedrow: can you tag the historic (non)release ? There is also the problem of not tagging on master. For instance the branch point for 3.1 (9a172d3) is not tagged either. Suggest using v3.1 and v3.2rc1 for these.

[TafThorne]

I was looking at tagging these. I can see that there is a 3.1 tag already in place that points at 9a09372. This does not agree with the last comment by @afbjorklund

I can generate a distcc-3.2rc1 tag that points to 1dc8c00 which to me looks like it is 3 years newer than the 3.1 tag. Is that correct?

I should probably be cardful not to much up any work done in #178 by @paranormal and @afbjorklund By my reconing what they have done should end up being rc3.2rc2 though.

[afbjorklund]

I chose to tag the master branch, so that git describe --tags and friends work... There are no code changes between 9a172d3 and 9a09372. The same goes for distcc-3.2rc1(.tar.gz) and 1dc8c00:

Only in distcc: .git
Only in distcc: Makefile
Only in distcc: aclocal.m4
Only in distcc: autom4te.cache
Only in distcc: config.log
Only in distcc: config.status
Only in distcc/contrib: distccd-on-servers
Only in distcc: distcc-3.2rc1.NEWS
Only in distcc: distcc-3.2rc1.tar.bz2
Only in distcc: distcc-3.2rc1.tar.gz
Only in distcc/doc/example: README
Only in distcc/doc/example: default
Only in distcc/doc/example: hosts.allow
Only in distcc/doc/example: services
Only in distcc/doc: protocol-3-impl.txt
Only in distcc/doc: protocol-3.txt
Only in distcc/doc: protocol-gssapi.txt
Only in distcc/doc: web
Only in distcc/lzo: .stamp-conf
Only in distcc/popt: .stamp-conf
Only in distcc: pump
Only in distcc/src: config.h

So the differing files are either generated by ./autogen.sh or by make dist itself ? Most likely those documentation files should have been included (in pkgdoc_DOCS in Makefile.in, that is)

[afbjorklund]

Here are the tags that I did (on master):

• d0cda33 (tag: v3.0) Change version number to "3.0", and update NEWS file and ChangeLog.
• 3031c5b (tag: v3.0rc1) Improve wording and accuracy of claims.
• be3a3e2 (tag: v3.0rc2) Update NEWS file and ChangeLog for distcc 3.0rc2.
• 51b2803 (tag: v3.0rc3) Update ChangeLog again to catch the last few changes before distcc 3.0rc3.
• 9a172d3 (tag: v3.1) Update ChangeLog with some more changes for distcc 3.1.
• 1dc8c00 (tag: v3.2rc1) Update ChangeLog again.

This was to not conflict with the existing distcc-*, that happened on maintenance branches...
It just enables you to do a git describe --tags, and get some more sensible output again ?

v3.2rc1-76-g6f886a5

[TafThorne]

I shall copy these over to the GitHub release notes fields: https://github.com/distcc/distcc/tags

Probably means I do not have to do much historic work for the roadmap (see distribution email if you care).

[TafThorne]

I have knocked up draft releases in GitHub based on the details above:

Presumably if I was to publish them it would look similar to this but without the "draft" note. All the rc builds I marked as "preliminary" in GitHub.

I chose to try numbering things in the style suggested by GitHub. I do not know if calling the release v3.1.0 when the shipped code calls itself v3.1 is going to be confusing. It would allow is to apply a modern veneer to things though. At least this way we could do a v3.1.1 maintenance and have it fit in the GitHub presented scheme even if the tags behind it look a little odd.

Final note is that I did not do a v3.2.0-rc1 release as that tag is not yet visible to me on either master of the current 3.2 branch. It looks like it would be simple to add once the tag is published or merged in.

[thinrope]

Hey, GREAT! Go ahead and publish those and let's start from there.

I don't expect millions of people and hundreds of distributions to start wanting to use the old releases, but I hope it will be enough drive for them to switch to GitHub as the official way to distribute distcc for the future! I'll try to prepare Gentoo ebuilds ASAP after the publishing.

The only question is why are those in jumbled order (on the picture)? I guess it will fix itself once published.

[TafThorne]

Hey, GREAT! Go ahead and publish those and let's start from there.

I might try to compile a short list of features or fixes in each of the non-rc ones first in case it makes some grand announcement. That will also give other people at least the weekend to comment on what I have done and the user of GitHub style semantic versioning.

I don't expect millions of people and hundreds of distributions to start wanting to use the old releases,

No. I expect the greatest value will be in showing the project is not stone dead and to provide some consistency with any future plans.

... for them to switch to GitHub as the official way to distribute distcc for the future!

Indeed. If we do generate a new stable maintenance release or anything else it would be good to see it start to trickle through.

I'll try to prepare Gentoo ebuilds ASAP after the publishing.

Thank you. We should probably do some basic testing just to make sure nothing weird has happened in the 8 years since the binaries were last published. Although I expect most distributions were using the code to roll their own which should mean everything is much as it was.

The only question is why are those in jumbled order (on the picture)? I guess it will fix itself once published.

I wish I knew. I started off doing them in the order that Anders had posted and after doing 3 of them I thought they were in the order I entered. So I deleted them and started again, doing them in the order they occurred. Then they ended up in a seemingly random order as shown.

[MikeMcQuaid]

@TafThorne Would great to have these published so downstreams (I'm a Homebrew maintainer) could migrate from the now-404ing Google Code tarballs. Even if it's just e.g. 3.2rc1 or a new version based on the the current master for now that'd be great. Thanks again for the work you're doing!

[TafThorne]

I have now published the releases on GitHub.

Next job will be to tag 1dc8c00 as v3.2rc1 to match @afbjorklund 's statement earlier.

[TafThorne]

I tagged the release in my fork and then pushed it. Then realised I cannot merge request tags :-(

Happily I have discovered that I can push and pull straight into the proper distcc repository! So I have now created tag v3.2rc1 and marked it is a preliminary release v3.2rc1 on the release page.

If it has been kicking around in the word for many years, we could move from beatification to canonization of Release 3.2 (or possible 3.2.0 if we are moving to the Semantic Versioning 2.0.0 system) without much further testing.

[TafThorne]

To tidy up I have:

• Closed this issue, now the tag is in place
• Created a 3.2 milestone, so we can decide if anything else needs done before we generate 3.2

A few people might want to eyeball v3.2rc1...master and see if there is stuff which should go into a 3.2rc2.

[afbjorklund]

Thanks for doing the tagging. If you want the source tarballs to be available, you need to upload those (after first doing a make dist, for the new releases). The old releases should use the old tarballs, so that the checksums match what people are expecting. The "dist" tarball has all the autotools stuff generated, unlike what you get when you clone from git. That is, so you don't have to run ./autogen.sh.

https://www.gnu.org/software/automake/manual/html_node/Dist.html

Old tarballs: https://code.google.com/archive/p/distcc/downloads

SHA1SUM

7564e4a4890ad6ff78ec0de620329b71179361e7  distcc-3.2rc1.tar.bz2
7cd46fe0926a3a859a516274e6ae59fa8ba0262d  distcc-3.2rc1.tar.gz
30663e8ff94f13c0553fbfb928adba91814e1b3a  distcc-3.1.tar.bz2
487ae2a73b0b1a0e6b240874319ca3ddda7287e8  distcc-3.1.tar.gz