On 19/09/2015 23:11, Branko Čibej wrote:
On 19.09.2015 22:43, Stefan wrote:
On 19/09/2015 22:23, Branko Čibej wrote:
Nothing would speak from my side against using that scheme, if that
would solve all the concerns also the others have.
I just got the idea that Johan's concern would not be solved by a
simple switch of the version scheme of the built binaries of MaxSVN.
If it does, I'll certainly use that one.
From the arguments I read so far on this list I just would not
understand how this would better solve the concerns than the other
scheme (I don't have to understand it, if it's suitable in the end ;-)
as said, whatever concerns any of u have I'll try my best to comply with).
I think Johan explained this quite clearly: whatever version scheme you
use, you should strive not to confuse users into thinking that something
has been release when it has not. Therefore, you can't use anything like
'1.10' because, even though 1.10 "exists" on trunk, it has not been
releaseed and, furthermore, may never be — we could, for some reason or
another, decide to release 1.11 instead.
This is completely clear to me and was why I thought that untangling the
version scheme from SVN's one by starting with 1.0-1.3 for the SVN
1.7-trunk releases would solve that concern.
Personally I would not choose that version numbering style because
this is so uncommon in the Windows world (as far as I know) and I
doubt that anybody besides SVN developers would easily understand it.
Therefore, I thought this wouldn't be a good style to go with. On the
other side MaxSVN is aiming primarily for SVN developers/supporters,
so this should certainly be ok to go with given that audience.
I find that many, many vendors use quite different versioning schemes
than Microsoft; and even they use wildly different schemes for published
product names vs. versions of component names (a good example is Visual
Studio 2015, which is really version 14.0). So there's hardly any common
scheme in the Windows world.
The case of VS 2015 is that a product name differs from its actual
version number. This is not too uncommon. But when it comes to version
numbering I really have a hard time finding examples which are quite
common in the Linux world (like the Debian patch-versions/-builds, etc.).
Anyway, this is a different story. :-)
Just so u get why I personally don't like this:
I like version numbers where it's obvious from the version itself
which one comes first and which one is a following/successive one.
With that style, this won't always work.
Assume there's now (random order to make the point clear):
maxsvn-trunk-r1704087-1
maxsvn-1.9.x-r1704598-1
maxsvn-1.9.15-1
maxsvn-1.9.x-r1704598-2
maxsvn-1.10.1-1
maxsvn-trunk-r1804087-1
which one comes first here? was trunk-r1804087 a version before 1.10
was released or is it a release of trunk which is after 1.10 was
branched off?
What about trunk-r170487-1?
Where does 1.9.15-1 sort into here?
You can call it 1.9.15-r1704598-1 using the revision in svn_versino.h,
if that helps. Although not that "what comes first" does not have an
unequivocal answer, since we're maintaining parallel release branches
... for example, 1.7.21, 1.8.14 and 1.9.0 all have the exact same
revision number in svn_version.h .. which one comes first? :)
Well, logically you would order all 1.7.x before any 1.8 version. By
"what comes first" I was merely speaking feature/logical/version wise,
not necessarily time-wise. This is quite clear for the x.y.z format, but
not that much for the 1.9.x vs. 1.9.15 vs. trunk format.
For SVN development I fully agree that this version scheme makes
absolute sense and is all fine. But for the sake of a distribution
this certainly wouldn't be my first choice. :-)
As said, if all of u are fine with using that version scheme for
MaxSVN I'm going to switch it to that one. Just want to make sure this
time that it certainly will be ok, so I won't spend another day on
adjusting the scheme. :-)
At the end of the day, it's your decision what kind of scheme you use.
You can decide to call it "MaxSVN 2015 Collectors Edition with Extra
Bells and Whistles" and not mention the Subversion version number at all. :)
I like the name. Maybe I'd pick that then? :-)
Leaving the joking behind:
So to keep things simple and stop wasting more of our time on that
matter, this is the current suggestion (based on the original version
scheme):
MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1
Filenames will be named exactly like the version number scheme aka:
maxsvn_1.8.x-dev-r1701493-1.zip
I'll wait at least till Friday next week to give everybody some time to
raise his concern and/or state his opinion on it. Afterwards I'll adjust
the few existing releases to match the updated version scheme.
Regards,
Stefan
