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
Received on 2015-09-19 23:30:21 CEST