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*.
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.
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/
Regards,
Evgeny Kotkov
Received on 2015-09-17 01:39:14 CEST