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.
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, 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.
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.
-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’t 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" <[email protected]> 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 <[email protected]> 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
--
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
[email protected]
http://www.nationallibrary.fi
