First of all thanks for ur input and time Evgeny.
> Stefan Hett <luke1410_at_gmx.de> writes:
>
>> What would u say about this other scheme:
>> 1.9.1.1 -> 1.9.1-1-r1694136-dev
>> 1.9.1.2 -> 1.9.1-2
>> 1.9.2.1 -> 1.9.2-1-r1701493-dev
>>
>> i.e. 1.9.1.2 is a tag-based build on the 1.9.1 branch (therefore it won't
>> suffix the revision number and dev suffix).
>>
>> Given that change, I'm even thinking whether the -dev suffix is still
>> required in the version number or whether it can be dropped completely as
>> in:
>> 1.9.1.1 -> 1.9.1-1-r1694136
>> 1.9.1.2 -> 1.9.1-2
>> 1.9.2.1 -> 1.9.2-1-r1701493
>>
>> Any thoughts would be very much appreciated.
> I'd say that both of this variants still are quite misleading. A version
> cannot refer to something that *does not yet exist*.
My thinking here (from the point of MaxSVN) would be that while the
final version doesn't exist yet, the work towards that version certainly
already exists. But I also see ur point, of course.
> 1.9.2-1-r1701493 actually means "Subversion 1.9.2 + my custom label". This
> is misleading, because Subversion 1.9.2 doesn't exist at this point of time.
> Moreover, there are situations when a certain patch release is skipped, e.g.,
> Subversion 1.8.12 was not released [1], so it's incorrect to label something
> with the "expected next version". The same applies to 1.10.0-1-... builds
> that could be misinterpreted as the actual 1.10 builds, while they are just
> built from /trunk.
For the case of a skipped SVN version, the result in MaxSVN's current
version scheme would be that following
1.8.12.x would be 1.8.13.1
With the addition of (let's say a -dev suffix for dev built versions)
that would be:
1.8.12.x-dev would follow 1.8.13.1 (i.e. there would not be a 1.8.12.x
version without the -dev suffix in the 1.8.12.x release chain.
> So, the version should not contain something like "1.9.2" unless 1.9.2 is an
> existing official release.
>
> Here is what I can suggest:
>
> - MaxSVN-1.9.1-x64
> (a binary package of Subversion 1.9.1 from /tags/1.9.1)
>
> - MaxSVN-1.9.x-dev-r1701493-x64
> (a development build built from /branches/1.9.x_at_r1701493)
>
> - MaxSVN-trunk-dev-r1701493-x64
> (a development build built from /trunk_at_r1701493)
>
> [1] https://archive.apache.org/dist/subversion/
Problem with this scheme is that it won't produce different version
numbers for new MaxSVN releases if these are based on the same
revision/version of SVN.
This is quite the norm of MaxSVN, because there will be builds for
instance for 1.7.22 whenever one of the dependencies (let's say APR)
gets updated. A simple MaxSVN-1.7.22-x64 won't work here, since that one
was already released.
The same problem applies to dev-builds (if the revision number doesn't
change).
For trunk builds it's not obvious to the user from the version number
alone which development chain this one is based on when new major
releases are tagged (aka: is it a version before 1.9 or is it one
already on the way towards 1.10 after 1.9 was released).
I'd imagine the following style could work (it's related to the version
numbering from Visual Assist X (from Wholetomato)):
- MaxSVN-1.9.1-x64 (build 1)
- MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
- MaxSVN-1.10.0-dev-r1701493-x64 (build 1)
Whenever there'd be another release of MaxSVN without the underlying SVN
source changing, the build counter would increase, while the rest stays
the same.
But to me this looks even more complicated than the previously suggested
style.
I also prefer to keep the version part determining the logical order of
releases at the beginning of the version number, so it's easier to get
the incremental order right.
Guess I've to think a bit more about that one, but most likely will go
with a combination of ur and Ivan's suggestion and my originally
proposed scheme.
Further input is more than welcome.
Regards,
Stefan
Received on 2015-09-19 12:36:55 CEST