I didn't want to touch the build numbers issue directly because I did
not read all of that recent, related discussion about the VM versions.

What is the purpose of each number? I thought the release version
number ("5.1", "5.2 Trunk", ...) exists for publicity reasons and to
find out if you should consider to "upgrade" your Squeak. The build
number allows you to refer to a specific version/configuration, mainly
for issue hunting, right? Can't we treat build numbers and release
numbers independently from each other then? If yes, we could simply
apply the Maven style version numbering (with "mutable" and
"immutable" versions) to the release version numbers. It is very
similar to what Tobias suggested, though, so you might as well
consider my Maven paragraph as supporting Tobias' suggestion. ;-)
"Squeak x.y" then just happens to also have a build number z, by
chance. That's the current situation anyway, is it? If the release
branch is updated, I would prefer if the patch number of that release
were increased at the same time, instead of referring to a different
build number for that release from now on.

I don't know how an update map is made up, but would it be possible to
version its configuration/state just like regular configurations,
packages, or baselines? Then you could just use its SCM version number
(hash/uuid, consecutive number if available, or timestamp) instead of
summing up contained version numbers.


2016-06-27 12:44 GMT+02:00 Taeumel, Marcel <Marcel.Taeumel at hpi.de>:
> Jakob Reschke wrote
>> 2016-06-27 10:12 GMT+02:00 Taeumel, Marcel &lt;
>
>> Marcel.Taeumel@
>
>> &gt;:
>>>
>>> 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).
>
> Hi Jakob,
>
> you're right. This information would have to appear in the file name of the
> downloads on the website. Hmm... right now, our build number is the sum of
> all MCZ versions in the trunk update stream. The goal here is to find a
> simple solution for that branching thing. Maybe the combination of release
> number and build number is enough to discriminate.
>
> I do not quite get your example about Maven/Java. I think that you relate to
> the ideas of suffixing the Trunk versions with alpha, beta, rc1, ..., rcn,
> alpha, ... However, my previous comment addresses the naming of release
> versions only and the role of the respective build number. :-)
>
> I think that an alternative to summing up the MCZ versions could be to only
> show the most recent commit date/time of the packages in the update map.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Renaming-Squeak-s-system-version-from-Squeak-alpha-to-SqueakTrunk-tp4902398p4903565.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>