Stefan Hett <luke1410_at_gmx.de> writes:
> So unless some new arguments will influence my mind again, this is the
> version scheme I'd aim for:
> (magic numbers are temporary, I didn't quite check them yet)
> MaxSVN 18.104.22.168 -> MaxSVN 1.7.22_0-1
> MaxSVN 22.214.171.124 -> MaxSVN 1.7.22_0-2
> MaxSVN 126.96.36.199 -> MaxSVN 1.8.14_0-1
> MaxSVN 188.8.131.52 -> MaxSVN 1.8.14_42-1
> MaxSVN 184.108.40.206 -> MaxSVN trunk-dev-r1697405-1
> MaxSVN 220.127.116.11 -> MaxSVN trunk-dev-r1701565-1
I am thinking that 1.8.14_42-1 could be err..., surprising.
Here is what it looks like if I try to put myself in the users' shoes.
I am looking for Subversion 1.8, and I would love it to work without problems.
At some point I stumble across MaxSVN, and here is what I see:
Perhaps, I could also see this, depending on how the versions are sorted:
"The bigger the number the better the build, right?", I say to myself and
start downloading MaxSVN 1.8.14_42-1. Well, wrong, because it is based
on a snapshot of the branch and not on the released version.
So, why not have a scheme that uses tag names when you build from a tag,
branch names when you build from a branch, and trunk when you build from trunk?
You could split the builds in two separate groups when presenting to the user,
say, like this:
Worth mentioning, I am not that sure about the necessity of having different
builds (like 1.9.0-1 and 1.9.0-2) based on the same source. You could probably
get rid of them by only using new dependencies for new builds.
In other words, when you build MaxSVN 1.9.0 and upload it, it is immutable.
You could then update APR version in MaxSVN 1.9.1, if you feel like it. Doing
so would turn the scheme into something fairly common and easy to understand:
Received on 2015-09-23 20:12:49 CEST