On 31/07/13 07:49, Claude Warren wrote:
I thought that the releases would be locked.
I have been trying to release my Security framework but there are 2 bugs in
the test suite that keep me from doing so. I'll make the patches in
2.10.2. and ensure that the framework works with that release.
Great.
If 2.10.2 is delayed does Apache Jena policy allow release of 2.10.1.1 ?
Yes, we get to choose any numbering we like.
We ought to ship 2.10.2 because (as seen in stackoverflow yesterday),
the jena-text component seems to be in use.
Maybe it should be 2.11.0?
Andy
Claude
On Tue, Jul 30, 2013 at 9:28 PM, Andy Seaborne <[email protected]> wrote:
On 30/07/13 20:41, Rob Vesse wrote:
Are you talking about changing an existing release or making a new
release?
If you want to change an existing release then I'm fairly sure that both
our (and Apache) policy is that we never do that and I would have strong
objections to any attempt to change that.
From a legal standpoint an Apache release represents the source at the
point in time that the PMC reviewed, voted on and approved. Modifying a
past release would invalidate that, this process is in place to protect
both the foundation and ourselves legally.
From a practical standpoint (particularly for Maven developers) if you
have a non-SNAPSHOT version for your dependencies (I.e a stable release)
then you assume they will never change. This is needed both to ensure
stable builds for consumers of our releases but also so people can go back
and build historically I.e. with the dependencies that were using at the
time. Also in the maven world once a stable release is downloaded to a
users local repository maven will never re-download it unless you
physically clean it out of your maven repo, the -U flag only updates
SNAPSHOTs and never updates stable releases.
Bottom line stable releases should be immutable.
Trunk is already deployed as maven SNAPSHOTs on a continuous basis by a
Jenkins job -
https://builds.apache.org/job/**Jena__Development_Deploy/<https://builds.apache.org/job/Jena__Development_Deploy/>-
which runs nightly. As a committer you can login with your Apache
credentials and force a build sooner if necessary.
If the build servers are going too slow, or are just having a bad day
(they are maintained by volunteers), you can do a build and deploy a
SNAPSHOT from your own machine.
Andy
Note that the Apache
build servers are highly contended so depending on what else is in the
Build queue this can be done in a few minutes or take a few hours.
Typically if I know there are fixes/changes that I need coming in the next
release then I will be using the SNAPSHOTs rather than the stable release
version as dependencies in my projects.
If you want to make a new release then that is perfectly fine. Jena
doesn't have any fixed release schedule rather we go ahead and make a new
release when people agree things are relatively stable and/or we have new
functionality we want to get into the hands of users/our own Jena based
projects. If you think this is the case then please start a new thread
proposing a 2.10.2 release, it has been a reasonable time since 2.10.1 so
it is likely people will be agreeable to this.
Rob
On 7/30/13 11:49 AM, "Claude Warren" <[email protected]> wrote:
What is the policy for updating the tag. I have a fix for JENA-488 that
I
would like to apply to 2.10.1 (and get the jar redeployed) as well as the
trunk. Is there any issue with doing this?
Claude
--
I like: Like Like - The likeliest place on the
web<http://like-like.xenei.com**>
Identity:
https://www.identify.nu/user.**[email protected]<https://www.identify.nu/[email protected]>
LinkedIn:
http://www.linkedin.com/in/**claudewarren<http://www.linkedin.com/in/claudewarren>
