[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Announcing MaxSVN

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Wed, 23 Sep 2015 21:12:19 +0300

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 1.7.22.1 -> MaxSVN 1.7.22_0-1
> MaxSVN 1.7.22.2 -> MaxSVN 1.7.22_0-2
> MaxSVN 1.8.14.1 -> MaxSVN 1.8.14_0-1
> MaxSVN 1.8.15.1 -> MaxSVN 1.8.14_42-1
> MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
> MaxSVN 1.10.0.2 -> 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:

  MaxSVN 1.8.14_0-1
  MaxSVN 1.8.14_42-1

Perhaps, I could also see this, depending on how the versions are sorted:

  MaxSVN 1.8.14_42-1
  MaxSVN 1.8.14_0-1

"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:

  MaxSVN 1.9.0-1
  MaxSVN 1.8.14-1
  MaxSVN 1.7.22-1
  MaxSVN 1.7.21-1

  MaxSVN trunk-dev-r1704854
  MaxSVN 1.9.x-dev-r1701565
  MaxSVN 1.8.x-dev-r1701493
  MaxSVN 1.7.x-dev-r1700845

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:

  MaxSVN 1.9.0
  MaxSVN 1.8.14
  MaxSVN 1.7.22
  MaxSVN 1.7.21

  MaxSVN trunk-dev-r1704854
  MaxSVN 1.9.x-dev-r1701565
  MaxSVN 1.8.x-dev-r1701493
  MaxSVN 1.7.x-dev-r1700845

Regards,
Evgeny Kotkov
Received on 2015-09-23 20:12:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.