I'm going to quote a big chunk of what Mark wrote.
Mark Phippard wrote in "Subversion's community health":
[...] I feel like the current release
policy is the only realistic way to encourage contributions to the
product because there are known and predictable release vehicles to
deliver those contributions. That said, those contributions are not
coming and the frequent releases themselves ARE causing pain. You list
some of it here.
As maintainer of Subclipse, the releases are an enormous problem for
me. The realities of the JavaHL API and JNI make it very difficult to
support multiple releases. At the Java API level it is all quite easy
the problem is in the delivery and just the details of
Subclipse/Eclipse/Java and the OS and native libraries. I will not go
into the details it is just that this situation creates a lot of bad
options to choose from and has made things difficult to the point where
I have to consider if it would not be better to just abandon the project.
This makes me feel so out of touch. I didn't realize it was such a pain
and I want Subversion to be a pleasure to package, to integrate, and to
work with for downstream consumers.
I know that's a big wish at this stage (with so much baggage and inertia
behind us) but let's try to make a change for the better.
In general, I would rather see us spend more effort supporting the
current release and only ever have another new 1.x release when some
significant new features were fully realized. Even if that means there
is never another new 1.x release.
When we decided to switch to faster releases we were looking almost
entirely from the perspective of developing new features and
improvements. But, as you say, this isn't happening.
Now that we recognize the gear shift to stabilization, I think this
makes it possible for us to decide to change (again) the way we deliver
upgrades.
It makes sense to me that we should be releasing incremental
improvements to a stable version, without making changes that require
extra effort downstream. Mostly we already are making incremental
improvements. The missing piece is we need to understand how our release
strategy generates the extra effort, and how we can change to a way that
does not.
It's easy to get hung up on the importance of the version numbers
themselves, the idea that a minor version number versus a patch release
number is The Thing we need to change. Of course, we understand
technically that the numbers are not the thing: instead the policies
about API versioning and the packaging and other usage mechanisms we've
put in place are the two things that matter. So let's be flexible in our
thinking, willing to change the numbering and/or the policies and practices.
Let me throw out a starting suggestion.
First the easy parts...
* Make just one kind of release from now on.
- Frequency is, let's say, every 6 months (April and October), if
there has been any change at all no matter how small, plus optionally
extra releases in between if and when we find it important and have the
resources to do so.
- We'll have to choose what version numbering to use. Either keep
the minor number at "1.12" from now on and increment the patch release
number, or just increment the minor number (1.13.0, 1.14.0, ...) and
don't use patch release numbers any more. But let's not focus on this
question initially because it unduly influences our thinking about the
meaning of new releases. Instead let's come back to this one after we've
decided the policies.
* Emphasis on stability.
- For each change we have already added in 1.12 compared with 1.10
LTS that is not a stable incremental improvement/fix, such as the
client-side shelving feature that is still "experimental", make it
opt-in so that users looking for long term stability don't see it, while
users looking for feature upgrades can set a config option and see it.
- Still allow contributions of feature development that is not
strictly incremental and stable, on condition that it's opt-in and
doesn't compromise stability otherwise.
And now the hard part...
What do we need to do with regard to API versioning, server protocol
version, etc. to make smooth consumption of upgrades?
* API changes must be strictly backwards- and forwards-compatible?
(Like our current rules for patch releases.)
- but that seems too restrictive
OR
* Each version can add APIs but cannot remove or break existing APIs?
(Like our current rules for minor releases.)
Can we solve the main issues for you with something like this?
I am pretty happy with SVN 1.8.x and that is still the only version I
run on servers. If SVN would slow down on new 1.x releases and was
going to just iterate fixes on the current release I might be more
inclined to move to it. But right now, on the server, it is just change
for change sake. There are some fixes but none that are super important
to me.
Well, I'm not sure what to make of your concern about the direction of
development, but if we now take a stabilization approach to future
releases, is this looking like we can make a better way forward?
Can anyone familiar with OS packaging, or other downstream uses, comment
as well?
- Julian
