Re: Releasing 1.6

> I'm just not sure that "sooner 1.6" has convinced enough people. We had
> a six-month plan for such releases, and releasing 1.6 so soon on the
> heels of 1.5 could cause some distress among the users. "Do I need to
> upgrade?" "What? I thought they just released 1.5?" Etc.

Finding that balance for release frequency will be tough. It does
_feel_ too soon for 1.6 but then in other projects (especially bazaar)
delivery of features happens every month - they're beating themselves
up right now over skipping a month and a half between 1.5 and 1.6.

Six months is a long time to wait with other projects delivering
features that much more often. Releasing more often will be necessary
just to keep Subversion relevant.

Having locked down our major version to what is effectively 'Product
Generation' we're quite limited in versioning choices. A four part
version number would allow us to get around that limitation. We need
to allow ourselves more scope to get features out quickly. We also
don't want to burden development with supporting many many versions
requiring a lot of patching. Assuming we don't do a Sun and change
Subversion 1.5.x to Subversion 5.x.y to free up a term in a three part
version - is there a strong reluctance to moving to a four part
version number?

Pfft - oops sorry, thinking about versioning gives be brain-gas.
Warning: Smelly odor below.

Let's say we have 4 feature releases (and I'm indicating that each
feature release some have had fix releases)

    1.2.0, 1.3.1, 1.4.6, 1.5.1

Now we want to make a feature release that doesn't require upgrade of
repos or bump the working copy and we want our versioning to indicate
that. Let's try a four part version number
(Generation.Major.Minor.Fix).

    1.2.0.0, 1.3.0.1, 1.4.0.6, 1.5.0.1

Now a minor feature added to the 1.5.x.x gives us 1.5.1.0

Now let's say that we support two major versions (current and
previous). We only need to patch the latest of 1.4.x.x and 1.5.x.x
lines giving us 1.4.0.7 and 1.5.1.1

Backporting a feature is similar... Deciding whether to reset fix
count when backporting is another consideration. EG backporting a
feature without resetting fix numbers.

1.4.1.7, 1.5.2.1

Reading 1.4.1.7 is
- Generation 1
- Version 4
- Feature updates 1
- Fix updates 7

Making fixes and features in the same release in a system where you
don't reset fix counts bumps both numbers EG 1.5.3.2 from 1.5.2.1
indicates features and fixes added.

Regardless of how we version these things the following seem good goals.

  Plan to do more minor releases - get features to users sooner.

  Continue to support the same depth of releases - ideally a similar
development effort in maintaining releases.

  Continue to target no more than one major release every six months -
since they require upgrade effort for repo bumps and coordinated tool
releases for working copy bumps.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org