[Buildbot-devel] Building tagged releases

[Oleg Smolsky]

On 2012-09-11 06:39, Greg Ward wrote:
> On 09 September 2012, Oleg Smolsky said:
>> Hey Dustin, here is a concrete example of what I am looking to do:
>>    - start with "v1" branch in Mercurial
>>    - commit a few changes into the branch
>>    - tag the tip of that branch as "build_50"
>>    - initiate a build off that tag as "v1.0.6 build=50"
> (Slightly OT, since this is mostly about Mercurial best practices.)
>
> Why not just create the 1.0.6 tag directly instead of build_50? If you
> tag every build, pretty soon you'll have a lot of tags. Hundreds or
> even a few thousand tags should be fine, but once you get up into tens
> of thousands, expect Mercurial performance to suffer.
>
> Directly tagging the release has lots of other benefits: "hg update
> 1.0.6" just works. "1.0.6" becomes a meaningful part of hgweb URLs,
> meaning people can download a source tarball directly from hgweb.
The point here is twofold: tag every public release and make multiple 
interim releases for internal QA.

This way we can actually have a meaningful conversation about releasing 
1.0.6:
  - so, how's build_50 looking?
  - all is well, except for bug X
  - ok, let me backport the fix into the stable_branch. Could you check 
the next build?
  - cool, build_51 is looking good

...and so 1.0.6 is actually build_51: the binary has the string, 
Mercurial has the tag, multiple builds can coexist and it is easy to 
find out what went into each one.

> Finally, be careful about branch vs. tag naming conventions. Mercurial
> won't stop you from creating branch "1.0" and tag "1.0"... but then
> what does "hg update 1.0" do? Offhand, I'm not sure. I'd have to check
> the code, and there's no guarantee that behaviour won't change in the
> future. Avoid the issue entirely and use distinct naming conventions
> for branches and tags.
>
right, that is the reason for having the "build_" prefix.

Oleg.