You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/07/30 20:49:10 UTC
updating tag
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.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: updating tag
Posted by Andy Seaborne <an...@apache.org>.
On 30/07/13 19:49, Claude Warren 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?
Once binaries are released, they are frozen. Two reasons:
1/ Maven does not allow or except releases to change - SNAPSHOTs yes,
releases, no. Once downloaded there is no requirement to check again.
2/ Apache releases (which are source code) are frozen for the downstream
redistributors. This is less of an issue for Java projects because
there are project produced (avoiding the word "officially" here)
binaries but only because of (1).
The project votes to release a specific set of source bytes and if a fix
is need, the way to do it is to re-release with a new version number.
Similarly, tags for releases should be considered fixed - they are part
of the vote.
If you fix it in svn, it'll be picked up by the nightly build of
2.10.2-SNAPSHOT. Is that OK? Or do you need a release for some reason?
Andy
>
> Claude
>
Re: updating tag
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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" <cl...@xenei.com> 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.**php?claude@xenei.com<ht...@xenei.com>
>>>> LinkedIn: http://www.linkedin.com/in/**claudewarren<http://www.linkedin.com/in/claudewarren>
>>>>
>>>
>>>
>>
>
>
Re: updating tag
Posted by Claude Warren <cl...@xenei.com>.
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.
If 2.10.2 is delayed does Apache Jena policy allow release of 2.10.1.1 ?
Claude
On Tue, Jul 30, 2013 at 9:28 PM, Andy Seaborne <an...@apache.org> 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" <cl...@xenei.com> 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.**php?claude@xenei.com<ht...@xenei.com>
>>> LinkedIn: http://www.linkedin.com/in/**claudewarren<http://www.linkedin.com/in/claudewarren>
>>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: updating tag
Posted by Andy Seaborne <an...@apache.org>.
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/ -
> 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" <cl...@xenei.com> 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.php?claude@xenei.com
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Re: updating tag
Posted by Rob Vesse <rv...@yarcdata.com>.
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/ -
which runs nightly. As a committer you can login with your Apache
credentials and force a build sooner if necessary. 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" <cl...@xenei.com> 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.php?claude@xenei.com
>LinkedIn: http://www.linkedin.com/in/claudewarren