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 <[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> >>> >> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
