2016-06-27 10:12 GMT+02:00 Taeumel, Marcel <Marcel.Taeumel at hpi.de>:
>
> Would it make sense to keep track of the release build number and show the
> current increment in a separate way? Releases are basically branches from
> Trunk. E.g.:
>
> source.squeak.org/trunk
> source.squeak.org/squeak50
>
> At release time, the code base is identical. Then, things might get
> cherry-picked from trunk into the release branch (here "squeak50"). Then,
> the summative build number would be confusing because "14023" in squeak50 is
> not the same as it is in trunk.
>
> What about doing it like GitHub branches and show "number of commits your
> are behind the main branch"? It could displayed like this:
>
> "Squeak 5.0 (Build 14000 +23/-324)"
>
> This means that the current image is a release image, created from trunk
> build 14000. There were 23 fixes in this branch since then and current Trunk
> is already 324 builds ahead.
>
> What do you think?

That looks very cryptic to me. IMHO, if you need to see your build's
detailed relation to the initial release or the current trunk, you
should ask the SCM system (Monticello) itself. If I were a newcomer,
these +/- numbers would confuse me when I want to download a specific
image version from the website. I would not expect someone to read a
manual to understand the version numbering.

For reference, in the Maven/Java world, artifacts get a version
suffixed with -SNAPSHOT until you do a "release". If you have an
artifact with a version of 1.2.3-SNAPSHOT you know that there will be
dozens of other builds with the same version number because the
snapshot suffix indicates that this number "1.2.3" has not been fixed
yet. That is, it is semantically equivalent to your current notion of
(or suffix) "trunk". If you do a release, you strip the -SNAPSHOT from
the version number (or rather jump to the intended fixed version
number), commit, tag, publish that version, then bump the version
number and append -SNAPSHOT again. The fixed version labelled "1.2.3"
is not expected to ever change again, so if you download one of these
artifacts, you can be quite sure it is identical to other "1.2.3"s of
that artifact you download later. I consider this a sufficient scheme
in many cases. However, it does not map to an alpha-beta-rc process,
unless you put that into the less significant parts of the version
number (which makes comparing versions harder for machines).