Stefan Hett <luke1...@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@r1701493) - MaxSVN-trunk-dev-r1701493-x64 (a development build built from /trunk@r1701493) [1] https://archive.apache.org/dist/subversion/ Regards, Evgeny Kotkov
