You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2017/01/23 17:31:58 UTC
Maintenance branches
On 23/01/17 07:24, Claude Warren wrote:
> The reasoning is that projects that use Jena will then have a stable
> platform upon which to build products and can deliver production code
> safe in the knowledge that Jena will not be changing out from
> underneath them.
This seems to me to be suggesting something like Ubuntu LTS versions,
not "pending next release". A whole separate branch of releases for
commercial systems.
I agree with Rob - if some contributions and commitments come in to do
that, excellent. I have backported a couple of fixes from Jena for work
reasons on work time but it's only "until the next version". But an LTS
is a long term commitment that needs resourcing. I'm not in a position
to volunteer.
On 23/01/17 11:04, Osma Suominen wrote:
> I mostly agree with Rob here. Managing multiple branches is likely
> painful and would need lots of resources.
>
> However, what about a model where after each release that release
> becomes a "stable" branch and then bugfixes (and only those) from the
> master/development branch are applied to that stable branch until the
> next release, when that release becomes the new "stable"? This is what
> we do with Skosmos, and it's been working mostly well. In most cases
> patches can simply be backported from the master branch using "git
> cherry-pick", so maintaining the stable branch is not a lot of extra work.
To expand on that: That would mean users could get source code to build
themselves, it would not be an "Apache release" and not in maven
central. For "products", the legal side of a release probably matters.
> Currently when a user discovers and reports a bug in Jena and it gets
> fixed in master, the user has to choose between waiting for the next
> release or using a snapshot,
or cherry picking - it's a distributed version control system!
> which may have other unrelated issues due
> to ongoing development. With a stable branch, there would be a third
> option - like the previous release, but with some bugs fixed.
If we want a proper release, it's a vote - quite doable, just needs
someone to do it.
> Obviously not everything can be easily applied to a stable branch, like
> Rob pointed out. Fixes that require architectural changes cannot simply
> be reapplied for an older version. But not all bugs are like that, so
> this would still be a net improvement for users.
Yes - in many ways, each situation is unique and needs a judgement
unless we have parallel development.
To date, Jena version have been very compatibility, especially at the
API level (see recent email on users@). We worry about changing
internal-but-accessible code.
Andy
>
> -Osma
>
> 23.01.2017, 12:41, Rob Vesse kirjoitti:
>> +1 to a new release
>>
>> On the topic on long-term support for specific releases we have always
>> been against this in the past because the active developer community
>> is simply not large enough to provide this.
>>
>> Also, it brings a lots of potential complexity in terms of managing
>> multiple branches and multiple versions of patches. With git you can
>> in principle simply rebase a branch against multiple branches creating
>> pull requests for each. However, this quickly becomes painful as
>> branches start to diverge from each other. You also sometimes run into
>> architectural limitations, resolving an issue might require
>> architectural changes that are breaking from the point of view of a
>> user and as such can only be implemented on master. The result of
>> which is older branches may have critical known deficiencies where the
>> only fix is to upgrade. Maybe that is acceptable, maybe it is not?
>>
>> There is also the question of how much you maintain between branches.
>> With performance improvements do you make them only to master or to
>> all maintained branches? Again this often leads into the architectural
>> issue mentioned above.
>>
>> I am not saying that we shouldn\u2019t do this eventually but it is my
>> experience is that projects that do have far more people at the
>> coalface or are maintaining multiple architectural lines e.g. Hadoop.
>>
>> Rob
>>
>> On 22/01/2017 23:24, "Claude Warren" <cl...@xenei.com> wrote:
>>
>> slightly off topic question. With a more frequent release cycle
>> are we
>> going to provide long term support for particular releases? I
>> would define
>> long term support as we provide patches for the long term versions
>> for a
>> longer period of time.
>>
>> The reasoning is that projects that use Jena will then have a stable
>> platform upon which to build products and can deliver production
>> code safe
>> in the knowledge that Jena will not be changing out from
>> underneath them.
>>
>> Claude
>>
>> On Sun, Jan 22, 2017 at 8:24 PM, Andy Seaborne <an...@apache.org>
>> wrote:
>>
>> > It's a little after 3 months since Jena 3.1.1
>> >
>> > We have this time:
>> >
>> > RDF Connection
>> > JENA-1267
>> >
>> > Serializable for Quad/triple/Node
>> > JENA-1233
>> >
>> > JsonLDReader: possibility to override the @context
>> > JENA-1279
>> > And jsonld-java upgarde to version 0.9.0
>> >
>> > jena-spatial - no longer sorts result.
>> > Big performance improvement.
>> > JENA-1277
>> >
>> > What else?
>> >
>> > What would the next release be?
>> >
>> > If we are moving jena-text/spatial on in the Lucene version,
>> should we
>> > call the next release 3.3.0?
>> >
>> > All JIRA marked as fixed in 3.2.0:
>> > https://s.apache.org/uhcd
>> >
>> > Andy
>> >
>> > Adam - are you still interested in being the RM? (If you don't
>> think you
>> > have time, that's fine.)
>> >
>> >
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> <http://like-like.xenei.com>
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>>
>>
>>
>>
>
>
Re: Maintenance branches
Posted by Dave Reynolds <da...@gmail.com>.
On 24/01/17 19:57, Andy Seaborne wrote:
>
>
> On 24/01/17 12:57, Osma Suominen wrote:
>> 23.01.2017, 19:31, Andy Seaborne kirjoitti:
>>
>>> To expand on that: That would mean users could get source code to build
>>> themselves, it would not be an "Apache release" and not in maven
>>> central. For "products", the legal side of a release probably matters.
>>
>> Source code yes, but I think it would make sense to set up some kind of
>> autobuilder for the stable branch, similar to how snapshots are built
>> nightly. It shouldn't be much effort to set this up, but it would be a
>> valuable service for users.
>
> It's not an Apache release.
>
> Snapshots are specifically allowed for developers which we include
> anyone picking and testing.
>
> They are not releases.
>
> Products that want LTS stability will, I believe, want:
> * The ASF release legal framework
> * Assurance that the LTS will be around for the life of the product
> * Ideally, support contracts (3rd party)
>
> It is likely because they don't have the technical capabilities or
> resources in-house to investigate and report, let alone fix.
>
> The trouble really comes when a "bug fix" is a feature change. If the
> bug is not some low thing like an NPE, one products view of a "fix" is
> another products regression.
>
> (Believe me! It's happing to me right now - a SPARQL fix to comply with
> the standard has causes interesting changes.)
>
> ---------------------------
>
> There are three options here:
>
> * Current
> Advantage: bug fixes, most timely.
> Disadvantage: picks up everything
>
> * A "last release+fixes" branch
> Not a release ... unless voted on
> Not long term stability (product life : years)
> Some extra work
>
> * LTS
> Long term commitment.
> More work.
>
> And a point about LTS - more bug reports are nice, but contributions of
> fixes is much better.
>
> I'm not convinced that item 2 would be much used - they last only 4 or 6
> months as I understand the concept.
>
> Events like Jena2->Jena3 are extremely rare. Otherwise, we add
> features, not remove them, backwards compatibility is as good as a
> stable branch (I would hope!). The low-cost way of careful adding to
> master seems to me best unless we have additional contributions of fixes
> (not just reports) or other resourcing.
+1
Excellent analysis and agreed that item 2 isn't likely be of much value.
I can see why people might want an LTS but it's just not practical for
us [says one who contributes very little these days]. Stick to current.
Dave
Re: Maintenance branches
Posted by Claude Warren <cl...@xenei.com>.
I was thinking about how IBM limits access to various products internally.
Basically Apache products have to be releases. All major releases have to
> be approved. Minor revision number changes are easily accepted. Anything
> else is a lot of paper (electron?) work. New releases mean regression
> testing and that can be a painful process. So for me (at work) 3.2.x is
> much easier to deal with the 3.2.x -> 3.3.0.
>
So I was looking for something like 3.2.0 being denoted as LTE would mean
that any bug fixes would be 3.2.x So if 3.3.0 is released the bug fixes
still get applied to 3.2 for some period of time.
So basically the standard LTE.
However, I can see that this poses problems with such a small development
team and without a major commercial backer. Having seen the discussion, I
think we might be well served to just continue on as we have until someone
declares they want to manage an LTE release scheme.
Thank you all for the discussion and the many points raised.
Claude
On Tue, Jan 24, 2017 at 8:15 PM, ajs6f@virginia.edu <aj...@virginia.edu>
wrote:
> I think Claude introduced the idea of LTS releases, so I'm curious about
> whether he thinks that the audience for stability includes people who would
> use a "stable" series of the kind Osma describes, even without the Apache
> imprimatur.
>
> ajs6f
>
> > On Jan 24, 2017, at 2:57 PM, Andy Seaborne <an...@apache.org> wrote:
> >
> >
> >
> >> On 24/01/17 12:57, Osma Suominen wrote:
> >> 23.01.2017, 19:31, Andy Seaborne kirjoitti:
> >>
> >>> To expand on that: That would mean users could get source code to build
> >>> themselves, it would not be an "Apache release" and not in maven
> >>> central. For "products", the legal side of a release probably matters.
> >>
> >> Source code yes, but I think it would make sense to set up some kind of
> >> autobuilder for the stable branch, similar to how snapshots are built
> >> nightly. It shouldn't be much effort to set this up, but it would be a
> >> valuable service for users.
> >
> > It's not an Apache release.
> >
> > Snapshots are specifically allowed for developers which we include
> anyone picking and testing.
> >
> > They are not releases.
> >
> > Products that want LTS stability will, I believe, want:
> > * The ASF release legal framework
> > * Assurance that the LTS will be around for the life of the product
> > * Ideally, support contracts (3rd party)
> >
> > It is likely because they don't have the technical capabilities or
> resources in-house to investigate and report, let alone fix.
> >
> > The trouble really comes when a "bug fix" is a feature change. If the
> bug is not some low thing like an NPE, one products view of a "fix" is
> another products regression.
> >
> > (Believe me! It's happing to me right now - a SPARQL fix to comply with
> the standard has causes interesting changes.)
> >
> > ---------------------------
> >
> > There are three options here:
> >
> > * Current
> > Advantage: bug fixes, most timely.
> > Disadvantage: picks up everything
> >
> > * A "last release+fixes" branch
> > Not a release ... unless voted on
> > Not long term stability (product life : years)
> > Some extra work
> >
> > * LTS
> > Long term commitment.
> > More work.
> >
> > And a point about LTS - more bug reports are nice, but contributions of
> fixes is much better.
> >
> > I'm not convinced that item 2 would be much used - they last only 4 or 6
> months as I understand the concept.
> >
> > Events like Jena2->Jena3 are extremely rare. Otherwise, we add
> features, not remove them, backwards compatibility is as good as a stable
> branch (I would hope!). The low-cost way of careful adding to master seems
> to me best unless we have additional contributions of fixes (not just
> reports) or other resourcing.
> >
> > Andy
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Maintenance branches
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
I think Claude introduced the idea of LTS releases, so I'm curious about whether he thinks that the audience for stability includes people who would use a "stable" series of the kind Osma describes, even without the Apache imprimatur.
ajs6f
> On Jan 24, 2017, at 2:57 PM, Andy Seaborne <an...@apache.org> wrote:
>
>
>
>> On 24/01/17 12:57, Osma Suominen wrote:
>> 23.01.2017, 19:31, Andy Seaborne kirjoitti:
>>
>>> To expand on that: That would mean users could get source code to build
>>> themselves, it would not be an "Apache release" and not in maven
>>> central. For "products", the legal side of a release probably matters.
>>
>> Source code yes, but I think it would make sense to set up some kind of
>> autobuilder for the stable branch, similar to how snapshots are built
>> nightly. It shouldn't be much effort to set this up, but it would be a
>> valuable service for users.
>
> It's not an Apache release.
>
> Snapshots are specifically allowed for developers which we include anyone picking and testing.
>
> They are not releases.
>
> Products that want LTS stability will, I believe, want:
> * The ASF release legal framework
> * Assurance that the LTS will be around for the life of the product
> * Ideally, support contracts (3rd party)
>
> It is likely because they don't have the technical capabilities or resources in-house to investigate and report, let alone fix.
>
> The trouble really comes when a "bug fix" is a feature change. If the bug is not some low thing like an NPE, one products view of a "fix" is another products regression.
>
> (Believe me! It's happing to me right now - a SPARQL fix to comply with the standard has causes interesting changes.)
>
> ---------------------------
>
> There are three options here:
>
> * Current
> Advantage: bug fixes, most timely.
> Disadvantage: picks up everything
>
> * A "last release+fixes" branch
> Not a release ... unless voted on
> Not long term stability (product life : years)
> Some extra work
>
> * LTS
> Long term commitment.
> More work.
>
> And a point about LTS - more bug reports are nice, but contributions of fixes is much better.
>
> I'm not convinced that item 2 would be much used - they last only 4 or 6 months as I understand the concept.
>
> Events like Jena2->Jena3 are extremely rare. Otherwise, we add features, not remove them, backwards compatibility is as good as a stable branch (I would hope!). The low-cost way of careful adding to master seems to me best unless we have additional contributions of fixes (not just reports) or other resourcing.
>
> Andy
Re: Maintenance branches
Posted by Andy Seaborne <an...@apache.org>.
On 24/01/17 12:57, Osma Suominen wrote:
> 23.01.2017, 19:31, Andy Seaborne kirjoitti:
>
>> To expand on that: That would mean users could get source code to build
>> themselves, it would not be an "Apache release" and not in maven
>> central. For "products", the legal side of a release probably matters.
>
> Source code yes, but I think it would make sense to set up some kind of
> autobuilder for the stable branch, similar to how snapshots are built
> nightly. It shouldn't be much effort to set this up, but it would be a
> valuable service for users.
It's not an Apache release.
Snapshots are specifically allowed for developers which we include
anyone picking and testing.
They are not releases.
Products that want LTS stability will, I believe, want:
* The ASF release legal framework
* Assurance that the LTS will be around for the life of the product
* Ideally, support contracts (3rd party)
It is likely because they don't have the technical capabilities or
resources in-house to investigate and report, let alone fix.
The trouble really comes when a "bug fix" is a feature change. If the
bug is not some low thing like an NPE, one products view of a "fix" is
another products regression.
(Believe me! It's happing to me right now - a SPARQL fix to comply with
the standard has causes interesting changes.)
---------------------------
There are three options here:
* Current
Advantage: bug fixes, most timely.
Disadvantage: picks up everything
* A "last release+fixes" branch
Not a release ... unless voted on
Not long term stability (product life : years)
Some extra work
* LTS
Long term commitment.
More work.
And a point about LTS - more bug reports are nice, but contributions of
fixes is much better.
I'm not convinced that item 2 would be much used - they last only 4 or 6
months as I understand the concept.
Events like Jena2->Jena3 are extremely rare. Otherwise, we add
features, not remove them, backwards compatibility is as good as a
stable branch (I would hope!). The low-cost way of careful adding to
master seems to me best unless we have additional contributions of fixes
(not just reports) or other resourcing.
Andy
Re: Maintenance branches
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
I've had some experience with protocols such as are described by Osma and I think that they have real value for (particularly for large) users and sites. And as he says, they can be automated. I would be willing to help with that. I would like to learn more about Apache infrastructure.
That having been said, I must also agree with Andy that, much as we might like to provide them, true LTS releases are probably beyond our strength right now. I wonder if any vendors are currently offering such a product?
ajs6f
> On Jan 24, 2017, at 7:57 AM, Osma Suominen <os...@helsinki.fi> wrote:
>
> 23.01.2017, 19:31, Andy Seaborne kirjoitti:
>
>> To expand on that: That would mean users could get source code to build
>> themselves, it would not be an "Apache release" and not in maven
>> central. For "products", the legal side of a release probably matters.
>
> Source code yes, but I think it would make sense to set up some kind of autobuilder for the stable branch, similar to how snapshots are built nightly. It shouldn't be much effort to set this up, but it would be a valuable service for users.
>
>>> Currently when a user discovers and reports a bug in Jena and it gets
>>> fixed in master, the user has to choose between waiting for the next
>>> release or using a snapshot,
>> or cherry picking - it's a distributed version control system!
>
> You're right, but it takes some effort and understanding of the git tree and how to build it.
>
>>> which may have other unrelated issues due
>>> to ongoing development. With a stable branch, there would be a third
>>> option - like the previous release, but with some bugs fixed.
>>
>> If we want a proper release, it's a vote - quite doable, just needs
>> someone to do it.
>
> Yes, having more frequent releases and distributing the RM burden further are both excellent new developments. If new releases are made frequently, there is less need for a stable branch.
>
> I'm not proposing creating such a stable branch at the moment, just pointing out that if we want to better serve users who need a (semi-)supported non-development version, a stable branch like this could be a solution that wouldn't require much extra effort from the developers.
>
> -Osma
>
> --
> Osma Suominen
> D.Sc. (Tech), Information Systems Specialist
> National Library of Finland
> P.O. Box 26 (Kaikukatu 4)
> 00014 HELSINGIN YLIOPISTO
> Tel. +358 50 3199529
> osma.suominen@helsinki.fi
> http://www.nationallibrary.fi
Re: Maintenance branches
Posted by Osma Suominen <os...@helsinki.fi>.
23.01.2017, 19:31, Andy Seaborne kirjoitti:
> To expand on that: That would mean users could get source code to build
> themselves, it would not be an "Apache release" and not in maven
> central. For "products", the legal side of a release probably matters.
Source code yes, but I think it would make sense to set up some kind of
autobuilder for the stable branch, similar to how snapshots are built
nightly. It shouldn't be much effort to set this up, but it would be a
valuable service for users.
>> Currently when a user discovers and reports a bug in Jena and it gets
>> fixed in master, the user has to choose between waiting for the next
>> release or using a snapshot,
> or cherry picking - it's a distributed version control system!
You're right, but it takes some effort and understanding of the git tree
and how to build it.
>> which may have other unrelated issues due
>> to ongoing development. With a stable branch, there would be a third
>> option - like the previous release, but with some bugs fixed.
>
> If we want a proper release, it's a vote - quite doable, just needs
> someone to do it.
Yes, having more frequent releases and distributing the RM burden
further are both excellent new developments. If new releases are made
frequently, there is less need for a stable branch.
I'm not proposing creating such a stable branch at the moment, just
pointing out that if we want to better serve users who need a
(semi-)supported non-development version, a stable branch like this
could be a solution that wouldn't require much extra effort from the
developers.
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi