Re: What comes after 1.12?

[Mark Phippard]

On Wed, Aug 21, 2019 at 6:47 AM Stefan Sperling  wrote:

> On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote:
> > In my specific scenario with Subclipse things are just hard and I do not
> > think anything can be done to help. Since the native libraries for the
> API
> > we need lives outside of our control we always have a problem of the
> > version to support.  I cannot just live on the latest version when the
> > major Unix distros are on older versions etc.  Any solution is
> > complicated.  I do not think TortoiseSVN, as a counter example, has these
> > problems at all.  And the frequent releases I believe have historically
> > been good for that client to have.
>
> So it sounds like we can stick to the current release model after all?
>
> Short of fixing JavaHL API issues somehow (with class loaders or whatever),
> Subclipse could choose to be compatible with LTS releases only, could it
> not?
> This seems to be what some Linux distributions are doing now. I don't
> recall
> any other downstream projects raising concerns over our new release model.
>

This got sidetracked by me bringing up Subclipse.  Yeah I more or less plan
to just declare support for the LTS version. That said, this only really
might work because the WC format has not changed. If it does, then all bets
are off. TortoiseSVN is always going to use the latest version (and
should). On Windows, everyone has that installed which means their WC
format will be upgraded and that would mean all of their SVN clients also
need to be on that version.

As noted in the other thread, other than the work involved (which is an
issue), Subclipse has no technical problem supporting the latest version on
Windows. It just then creates problems for all the other OS where the user
maybe does not have that version and has to jump through hoops to install
the right older version for their OS.



> I would not want to change the release model again after such a short time
> frame. As long as we can manage to stick to the new schedule I think we
> should stick to it. Should we find that there is nothing to release after
> 6 months we can just skip or postpone a release. Should the schedule turn
> out
> to be unworkable in the long term we will have to change it again in any
> case.
>


As I have said, I think the project should do whatever is best for the
project.  I get how frequent releases may be the best way to attract new
contributors.  That said, so far it has not done that and in my case and
perhaps others, it may be driving me away from the project faster than I
otherwise would. New releases create a lot of downstream activity that I am
not always prepared to do and which forces me to weigh whether to continue
at all.  Dealing with a bunch of questions about "where is 1.12" etc. when
I know the release does not offer anything worth installing just makes me
consider walking away. As long as the project thinks it is getting value
from these releases, that is fine though.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: What comes after 1.12?

[Mark Phippard]

On Tue, Aug 20, 2019 at 7:04 PM Branko Čibej  wrote:

> On 20.08.2019 17:46, Julian Foad wrote:
> > Julian Foad wrote:
> >> [...] OR
> >>
> >>* Each version can add APIs but cannot remove or break existing
> >> APIs? (Like our current rules for minor releases.)
> >
> > Reading back what I've just written, it seems I'm completely missing
> > something. If we take that approach (API changes allowed), then
> > everything I wrote doesn't seem to amount to anything that would make
> > a real difference to you.
>
> I suspect that the real issue is that a consumer of JavaHL cannot
> trivially rely on compile-time version checks to decide which version of
> the API to use (and, as a consequence, which features it can expose). In
> Java, you have to do this with class loaders and other unspeakable
> horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
> promise backwards compatibility on that level.
>


At the Java source code level, yes we just write to the 1.8 API and that
works fine.  The problem is delivery.  We have to include that JavaHL "jar"
part of the API with Subclipse and that has to match the native libraries
because of how JNI works.  We cannot use the 1.8 JAR with native libraries
from a newer version.  Consequently, we have to provide Eclipse plugins for
each SVN version that delivers the right java part.  This is not too bad,
the problem is the user experience in Eclipse.  Its UI naturally wants to
encourage the user to install the latest version and so usually the user
runs into problems, hits a forum and maybe figures out how to uninstall the
plugin and install the right version for their native libraries.  The whole
thing sucks.

On Windows, we are able to provide the Java and the native due to some
hacks we are able to exploit in how DLL's are loaded and how JNI works.
There is no equivalent that works for other OS and something about the way
JNI loads libraries makes a static build not an option either. If it were
possible for us to deliver the native libraries then there would be less of
an issue.  Anyway, I am several years past the point where I would have had
enough time and interest to try to make it all work again anyway if an
option were possible.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: What comes after 1.12?

[Stefan Sperling]

On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote:
> In my specific scenario with Subclipse things are just hard and I do not
> think anything can be done to help. Since the native libraries for the API
> we need lives outside of our control we always have a problem of the
> version to support.  I cannot just live on the latest version when the
> major Unix distros are on older versions etc.  Any solution is
> complicated.  I do not think TortoiseSVN, as a counter example, has these
> problems at all.  And the frequent releases I believe have historically
> been good for that client to have.

So it sounds like we can stick to the current release model after all?

Short of fixing JavaHL API issues somehow (with class loaders or whatever),
Subclipse could choose to be compatible with LTS releases only, could it not?
This seems to be what some Linux distributions are doing now. I don't recall
any other downstream projects raising concerns over our new release model.

I would not want to change the release model again after such a short time
frame. As long as we can manage to stick to the new schedule I think we
should stick to it. Should we find that there is nothing to release after
6 months we can just skip or postpone a release. Should the schedule turn out
to be unworkable in the long term we will have to change it again in any case.

Re: What comes after 1.12?

[Julian Foad]

Julian Foad wrote:
It looks like we need to make this clearer. Thank you for those 
suggestions. I will make some changes.


Changed:
http://subversion.apache.org/download
http://svn.apache.org/r1865613
* download.html
  Add a notice of latest LTS release after notice of latest regular 
release.

  (#recommended-release): Change the title to "Latest regular release".
State the support period.
  (#supported-releases): Change the title to "LTS releases".
State the support period.
  Say "1.10 LTS" instead of just "1.10", and for 1.9, everywhere.

Please do let me know any other improvements you can think of!

- Julian

Re: What comes after 1.12?

[Julian Foad]

Thomas Singer wrote:

What are the LTS releases?


See https://subversion.apache.org/roadmap.html#release-planning

Is this somehow detectable by a user from the 
name? Ubuntu, for example, adds "LTS" to the name of their releases, 
e.g. "18.04 LTS". Maybe at




the title "Other Supported Release(s)" should rather be "LTS-Releases" 
with obvious indication how long they will receive support. And, of 
course, 1.10 should be named 1.10 LTS.


It looks like we need to make this clearer. Thank you for those 
suggestions. I will make some changes.


- Julian

Re: What comes after 1.12?

[Thomas Singer]

What are the LTS releases? Is this somehow detectable by a user from the 
name? Ubuntu, for example, adds "LTS" to the name of their releases, 
e.g. "18.04 LTS". Maybe at




the title "Other Supported Release(s)" should rather be "LTS-Releases" 
with obvious indication how long they will receive support. And, of 
course, 1.10 should be named 1.10 LTS.


Tom


On 21/08/2019 09:07, Julian Foad wrote:

Thomas Singer wrote:

Probably the thing that would help me the most would be if
the releases slowed down. If we want them on a schedule then do it

every 12

months instead of 6.


+1


But... we are doing releases on a 24-month schedule. We are calling those "LTS" 
releases. They correspond in purpose and stability and frequency to the old minor 
releases.

What is compelling you to do anything with the new "regular" 6-month releases 
in between LTS releases?

Or did we not communicate sufficiently about the new release schedule?
- Julian

Re: What comes after 1.12?

[Julian Foad]

Thomas Singer wrote:
>> Probably the thing that would help me the most would be if
>> the releases slowed down. If we want them on a schedule then do it
>every 12
>> months instead of 6.
>
>+1

But... we are doing releases on a 24-month schedule. We are calling those "LTS" 
releases. They correspond in purpose and stability and frequency to the old 
minor releases.

What is compelling you to do anything with the new "regular" 6-month releases 
in between LTS releases?

Or did we not communicate sufficiently about the new release schedule?
- Julian

Re: What comes after 1.12?

[Branko Čibej]

On 20.08.2019 17:46, Julian Foad wrote:
> Julian Foad wrote:
>> [...] OR
>>
>>    * Each version can add APIs but cannot remove or break existing
>> APIs? (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
> something. If we take that approach (API changes allowed), then
> everything I wrote doesn't seem to amount to anything that would make
> a real difference to you.

I suspect that the real issue is that a consumer of JavaHL cannot
trivially rely on compile-time version checks to decide which version of
the API to use (and, as a consequence, which features it can expose). In
Java, you have to do this with class loaders and other unspeakable
horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
promise backwards compatibility on that level.

-- Brane

Re: What comes after 1.12?

[Nathan Hartman]

On Tue, Aug 20, 2019 at 3:06 PM Branko Čibej  wrote:

> On 20.08.2019 20:50, Paul Hammant wrote:
> > If you all developed on trunk (patchsets for trunk, or direct to it),
> > and had an automated CI build setup that tested all permutations in
> > parallel, and a merging bot that attempted to cherry-pick commits
> > marked as [BUGFIX] back to all supported release branches without
> > human intervention (and Apache-TM votes), then you might have
> > streamlined things. Such a bot shouldn't shit the bed if the
> > cherry-pick fails *
>
> Duh. We have all that, except for the automated backport because no-one
> sane believes the word of *one* person that some [BUGFIX] commit is
> actually a viable candidate for any particular release branch. This is
> all documented in our community guide, which you'd be well advised to
> read before pontificating.
>

Yes. Someone definitely needs to LOOK at the "[BUGFIX]" commit first!

Re: What comes after 1.12?

[Branko Čibej]

On 20.08.2019 20:50, Paul Hammant wrote:
> My DevOps consulting life (around how to get to Trunk-Based
> Development from some often ClearCase inspired branching model),
> starts with what release cadence are you at now, and what do you want
> to get to.  Clients who are quartly want to get to monthly (and have
> less unplanned releases following each). Clients that are monthly want
> to get to weekly (same elimination on unplanned). Aaand clients that
> are weekky eye daily.  Sure that's dev teams of 20-1000 in one repo,
> where change would firehose into the repo if it could,
>
> *I've not encountered an enterprise team that wanted to slow down
> release cadence.*
>
> Seems to me Svn's problems are 1) lack of committers, perhaps because
> 2) patch contributors don't feel it matches their smoother experience
> elsewhere, and because 3) running "the build" from zero is hard, and
> 4) tests in the build isn't a super uniform thing.
>
> If you all developed on trunk (patchsets for trunk, or direct to it),
> and had an automated CI build setup that tested all permutations in
> parallel, and a merging bot that attempted to cherry-pick commits
> marked as [BUGFIX] back to all supported release branches without
> human intervention (and Apache-TM votes), then you might have
> streamlined things. Such a bot shouldn't shit the bed if the
> cherry-pick fails *

Duh. We have all that, except for the automated backport because no-one
sane believes the word of *one* person that some [BUGFIX] commit is
actually a viable candidate for any particular release branch. This is
all documented in our community guide, which you'd be well advised to
read before pontificating.

-- Brane

Re: What comes after 1.12?

[Paul Hammant]

My DevOps consulting life (around how to get to Trunk-Based Development
from some often ClearCase inspired branching model), starts with what
release cadence are you at now, and what do you want to get to.  Clients
who are quartly want to get to monthly (and have less unplanned releases
following each). Clients that are monthly want to get to weekly (same
elimination on unplanned). Aaand clients that are weekky eye daily.  Sure
that's dev teams of 20-1000 in one repo, where change would firehose into
the repo if it could,

*I've not encountered an enterprise team that wanted to slow down release
cadence.*

Seems to me Svn's problems are 1) lack of committers, perhaps because 2)
patch contributors don't feel it matches their smoother experience
elsewhere, and because 3) running "the build" from zero is hard, and 4)
tests in the build isn't a super uniform thing.

If you all developed on trunk (patchsets for trunk, or direct to it), and
had an automated CI build setup that tested all permutations in parallel,
and a merging bot that attempted to cherry-pick commits marked as [BUGFIX]
back to all supported release branches without human intervention (and
Apache-TM votes), then you might have streamlined things. Such a bot
shouldn't shit the bed if the cherry-pick fails *

Of course you're stymied by a lack of a integrated patch consumption
technology. Gerrit and Rietveld were made in Mondrian's image, ten years
ago. That said GitHub and pull requests a few months later stole the
spotlight and have not relinquished it since.  Julian's stash/shelve tech
is the start of a standardized Pull-Request system for Svn, but the vision
need to be expanded.

Meanwhile, Mononoke ** is pushing forward to monorepo-nirvana even if
Atlassian today declare that Mercurial support in BitBucket has an end
date.

* oh, the back-applying merge bot will work fine as long as no rename/move
refactorings happen in the Subversion tree. That's because Subversion can't
merge through rename (unlike Git and Mercurial - seamless). Perforce could
do it if you muck around with branch-specs, but nobody does.

** Mononoke (a Rust backend for Mercurial) is hosted on GitHub (Git). The
dev eam feels no shame from that, perhaps because it's a periodical copy
from the same source-tree inside Facebook (and isn't currently buildable).
Git made a Svn compatibility for GitHub's Git repos - I wonder if future
contributors to Mononoke could too. Repo:
https://github.com/facebookexperimental/mononoke

Re: What comes after 1.12?

[Thomas Singer]

Probably the thing that would help me the most would be if
the releases slowed down. If we want them on a schedule then do it every 12
months instead of 6.


+1

--
Thomas

Re: What comes after 1.12?

[Mark Phippard]

On Tue, Aug 20, 2019 at 11:46 AM Julian Foad  wrote:

> Julian Foad wrote:
> > [...] OR
> >
> >* Each version can add APIs but cannot remove or break existing APIs?
> > (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
> something. If we take that approach (API changes allowed), then
> everything I wrote doesn't seem to amount to anything that would make a
> real difference to you.
>
> Can you clarify the source of the difficulties you experience, and what
> we could change that would help?
>


I do not have any specific recommendations. I would say first and foremost
do what we think is best for this project and might help attract more
contributions. Probably the thing that would help me the most would be if
the releases slowed down. If we want them on a schedule then do it every 12
months instead of 6.  Maybe do more patch releases in between if we want to
get non API changes delivered sooner.

As I said before, I understand the idea behind frequent releases. That
said, with so little activity happening I am not in favor of us doing
releases because the calendar says we have to. If there is nothing worthy
of a release why are we pushing them so hard when it creates all of this
work for our community.

In my specific scenario with Subclipse things are just hard and I do not
think anything can be done to help. Since the native libraries for the API
we need lives outside of our control we always have a problem of the
version to support.  I cannot just live on the latest version when the
major Unix distros are on older versions etc.  Any solution is
complicated.  I do not think TortoiseSVN, as a counter example, has these
problems at all.  And the frequent releases I believe have historically
been good for that client to have.

Sorry not much help.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: What comes after 1.12?

[Julian Foad]

Julian Foad wrote:

[...] OR

   * Each version can add APIs but cannot remove or break existing APIs? 
(Like our current rules for minor releases.)


Reading back what I've just written, it seems I'm completely missing 
something. If we take that approach (API changes allowed), then 
everything I wrote doesn't seem to amount to anything that would make a 
real difference to you.


Can you clarify the source of the difficulties you experience, and what 
we could change that would help?


- Julian