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’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
