You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@epimorphics.com> on 2011/11/30 10:39:51 UTC
Jena release : suggested approach
tl;dr:
Let's release based on the current svn repo.
-------------------
There are 3 kinds of items to produce for a release:
1/ A "source-release" blob that firms the formal item to be voted on
(it's a maven artifact with classifier "source-release")
2/ Maven artifacts - the usual suspects.
3/ The download for use without maven
The RAT creates the "source-release" by taking a copy of svn at the
point of release. This state is also tagged in svn (e.g. maven release
plugin). The artifacts, including "source-release", are then deployed
to a staging repository and the votes can start.
The different parts of Jena are have different degrees of stability
which means, for now, releases of parts of the system will want to be
more frequently than others. Releasing everything too often means that
users of the stable parts (which is most of Jena) get a confusing message.
The RAT process for multi-module maven builds works if the project has a
single trunk, a POM in the trunk directory then a number of modules
including a parent. It does not work out-of-the-box with a layout of
trunk-per-module, which Jena has currently.
Long term, I think we should adopt that layout but, for now, I propose a
multiple build release with the current structure.
== What to release?
Proposal: JenaTop, IRI, Jena, ARQ, (?LARQ?) and a download.
That's 5 or 6 releases. :-(
But they are all the same pattern :-)
== Zip
To create a downloadable zip (and .tar.gz), I've put together an
artifact builder that takes it's dependencies (other Jena systems, and
their javadoc and sources), added in versions of the command line tools
that work with the download, to produce a single artifact.
I'd like to call that "apache-jena". The maven jars are called "jena-...".
e
The zip maker is also another Jena system and needs to be released. This
also gets round the fact that maven projects can only deploy one
artifact name, silently loosing or overwriting artifacts with different
names.
== Version number
I think it's worth bumping the minor version number on ARQ and Jena -
the jar files have changed name format; the maven artifacts have
different names, ARQ is SPARQL 1.1 (query, update) complete.
JenaTop 0
IRI 0.9.0
Jena 2.7.0
ARQ 2.9.0
LARQ?
Download 2.7.0 (in line with Jena core)
== Needed
Final clearing up:
A/ Remove doc/
B/ Turn off zip assemblies for IRI, Jena core and ARQ.
C/ test, fix, test, fix, test
D/ Write email announcements (I think we should hit the main semweb
lists this time round)
Then go for it. This should follow process of e.g.sling, except that
each system needs to be build-deployed-voted, not one thing. Not ideal,
it's 5 or 6 items, but it isn't actually much more work.
Of course, next time, it will be easier ...
== After
* Multi-module projects RAT-friendly layout [+]
* TDB
* Fuseki
Andy
Re: Jena release : suggested approach
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> On 30/11/11 13:31, Paolo Castagna wrote:
>> Andy Seaborne wrote:
>
>>> == After
>>>
>>> * TDB
>>> * Fuseki
>>
>> Yes, please.
>
> TDB as two outstanding blocking JIRA (163 and 102).
Ack.
JENA-163 is still a 'mystery' to me. I followed your comments and changes,
but I do not understand where the root cause of the bug is.
We had problems with .truncate() in the past and I went to check if that
was related, but I did not find anything 'interesting'.
JENA-102 is important, but less mysterious.
> Hopefully, after getting the release started, I'll be able to return to
> those.
>
>> For TDB, even just a release candidate in the Apache Maven staging
>> repository would help
>
> A staging release will have a weird, unstable URL (and a scary button
> that if you press irreversible things happen).
Ack.
> The nightly build does at least have a stable URL.
The nightly build is great and I use it when I develop (so that I can
stay up-to-date and identify eventual (and very rare) 'incompatible'
changes and fix them as soon as they happen, one at the time... rather
than all together at release time or version upgrade time).
This works very well for me.
But, the nightly build has -SNAPSHOT in it.
Therefore I cannot use the Maven release plugin to release internal
projects if they depend on TDB. This is not a big issue, but I need
to maintain a fork of TDB and roll out internal releases of it.
This will not be a problem anymore as soon as a release of TDB with
the transactional stuff in it is out.
(
I am sharing this for the benefit of others and as information.
I am not asking or expecting you or anyone to take any action on this.
)
>
>> (=> no need to fork and roll-out releases
>> internally/elsewhere). Via Maven release plugin this should just a
>> matter of type:
>>
>> mvn -Papache-release release:prepare
>> mvn -Papache-release release:perform
>>
>> I've never tested this on the Apache infrastructure,
>
> I have, at least in part :-)
Good.
I did not try since I was not sure if there are non reversible side effects.
>
>> but I am using
>> the Maven release plugin elsewhere with no problems. It's does a good
>> job in automating the all process. The only problem is when something
>> goes wrong, sometimes I need to rollback changes manually, but it's
>> very rare.
>>
>> Paolo
>
Thanks Andy for pushing forward towards a release.
Paolo
Re: Jena release : suggested approach
Posted by Andy Seaborne <an...@apache.org>.
On 30/11/11 13:31, Paolo Castagna wrote:
> Andy Seaborne wrote:
>> == After
>>
>> * TDB
>> * Fuseki
>
> Yes, please.
TDB as two outstanding blocking JIRA (163 and 102).
Hopefully, after getting the release started, I'll be able to return to
those.
> For TDB, even just a release candidate in the Apache Maven staging
> repository would help
A staging release will have a weird, unstable URL (and a scary button
that if you press irreversible things happen).
The nightly build does at least have a stable URL.
> (=> no need to fork and roll-out releases
> internally/elsewhere). Via Maven release plugin this should just a
> matter of type:
>
> mvn -Papache-release release:prepare
> mvn -Papache-release release:perform
>
> I've never tested this on the Apache infrastructure,
I have, at least in part :-)
> but I am using
> the Maven release plugin elsewhere with no problems. It's does a good
> job in automating the all process. The only problem is when something
> goes wrong, sometimes I need to rollback changes manually, but it's
> very rare.
>
> Paolo
Re: Jena release : suggested approach
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> Proposal: JenaTop, IRI, Jena, ARQ, (?LARQ?) and a download.
LARQ.
> I'd like to call that "apache-jena".
+1
Feel free to remove everything that clashes with "apache-jena" in the
Apache snapshot repository or elsewhere.
> LARQ?
As per pom.xml: 1.0.0-incubating-SNAPSHOT ==> 1.0.0-incubating
The Maven release plugin does that automatically.
> == After
>
> * TDB
> * Fuseki
Yes, please.
For TDB, even just a release candidate in the Apache Maven staging
repository would help (=> no need to fork and roll-out releases
internally/elsewhere). Via Maven release plugin this should just a
matter of type:
mvn -Papache-release release:prepare
mvn -Papache-release release:perform
I've never tested this on the Apache infrastructure, but I am using
the Maven release plugin elsewhere with no problems. It's does a good
job in automating the all process. The only problem is when something
goes wrong, sometimes I need to rollback changes manually, but it's
very rare.
Paolo
Re: Jena release : suggested approach
Posted by Andy Seaborne <an...@apache.org>.
On 30/11/11 13:54, Leo Simons wrote:
> On Wed, Nov 30, 2011 at 10:39 AM, Andy Seaborne
> <an...@epimorphics.com> wrote:
>> tl;dr:
>>
>> Let's release based on the current svn repo.
>
> I have read this e-mail and I have no objections to the things that I
> understood :-)
:-)
>
> Also, sorry, but I won't be able to review anything until Monday, I'll
> be traveling soon. Monday evening I'm your man!
Great! There'll be something concrete to poke at by then and it's likely
to be a bit rough. I have another 20 pages of "guide" to read and check.
>
> cheerio,
>
> Leo
Andy
Re: Jena release : suggested approach
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Nov 30, 2011 at 10:39 AM, Andy Seaborne
<an...@epimorphics.com> wrote:
> tl;dr:
>
> Let's release based on the current svn repo.
I have read this e-mail and I have no objections to the things that I
understood :-)
Also, sorry, but I won't be able to review anything until Monday, I'll
be traveling soon. Monday evening I'm your man!
cheerio,
Leo
Re: Jena release : suggested approach
Posted by Andy Seaborne <an...@apache.org>.
On 30/11/11 16:51, Thorsten Möller wrote:
>
> Am 30.11.2011 um 17:45 schrieb Thorsten Möller:
>
>>
>> Am 30.11.2011 um 17:26 schrieb Paolo Castagna:
>>
>>> Thorsten Möller wrote:
>>>> Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
>>>>
>>>>> == Version number
>>>>>
>>>>> I think it's worth bumping the minor version number on ARQ and Jena - the jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL 1.1 (query, update) complete.
>>>>>
>>>>> JenaTop 0
>>>>> IRI 0.9.0
>>>>> Jena 2.7.0
>>>>> ARQ 2.9.0
>>>>> LARQ?
>>>>> Download 2.7.0 (in line with Jena core)
>>>>
>>>> Does it mean version numbers of the download and Jena-core are kept in line just for this release or also for future releases? What if you want to release a new download (because of a critical bug in a non Jena-core module) while the version of Jena-core has not changed - fourth level 2.7.0.1?
We have to judge the importance of any fix on a case by case basis.
We can do various things but the easiest IMHO is to inc the download
version, and jump any jena-core version number for next time if
necessary. i.e. zip-2.7.1 with jena-core-2.7.0, next jena-core is 2.7.2.
Personally, I'm not inclined to be too quick to rebuild the download.
So fix ARQ, release, see if that is done, then see whether a new
download is needed.
If it's really serious and hitting a lot of people, then we do a whole
new release cycle.
Andy
>>>
>>> Hi Thorsten,
>>> I am not sure I completely understand your question.
>>>
>>> But, let's say a critical bug is found in jena-core 2.7.0.
>>
>> That's the innocuous case. Suppose the initial versions are Jena-Core 2.7.0 and 2.9.0 for ARQ. Then a critical bug is found and fixed in ARQ, a new release of ARQ is made having a new version number, say 2.9.0->2.9.1, and you want to provide a new/updated download. Then you either have the option of increasing the version of the download, say 2.7.0->2.7.1, which results in tying it apart from Jena core. Or you introduce a fourth level for the download 2.7.0.1, thereby keeping the first three levels in line with Jena core.
>
> Well, there is also a third option of appending a release date (or build number) after the version number, similar to how it is done in the Eclipse community (e.g., 4.1.1-201109121510).
>
> Thorsten
>
>
>>
>> Thorsten
>
Re: Jena release : suggested approach
Posted by Thorsten Möller <th...@unibas.ch>.
Am 30.11.2011 um 17:45 schrieb Thorsten Möller:
>
> Am 30.11.2011 um 17:26 schrieb Paolo Castagna:
>
>> Thorsten Möller wrote:
>>> Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
>>>
>>>> == Version number
>>>>
>>>> I think it's worth bumping the minor version number on ARQ and Jena - the jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL 1.1 (query, update) complete.
>>>>
>>>> JenaTop 0
>>>> IRI 0.9.0
>>>> Jena 2.7.0
>>>> ARQ 2.9.0
>>>> LARQ?
>>>> Download 2.7.0 (in line with Jena core)
>>>
>>> Does it mean version numbers of the download and Jena-core are kept in line just for this release or also for future releases? What if you want to release a new download (because of a critical bug in a non Jena-core module) while the version of Jena-core has not changed - fourth level 2.7.0.1?
>>
>> Hi Thorsten,
>> I am not sure I completely understand your question.
>>
>> But, let's say a critical bug is found in jena-core 2.7.0.
>
> That's the innocuous case. Suppose the initial versions are Jena-Core 2.7.0 and 2.9.0 for ARQ. Then a critical bug is found and fixed in ARQ, a new release of ARQ is made having a new version number, say 2.9.0->2.9.1, and you want to provide a new/updated download. Then you either have the option of increasing the version of the download, say 2.7.0->2.7.1, which results in tying it apart from Jena core. Or you introduce a fourth level for the download 2.7.0.1, thereby keeping the first three levels in line with Jena core.
Well, there is also a third option of appending a release date (or build number) after the version number, similar to how it is done in the Eclipse community (e.g., 4.1.1-201109121510).
Thorsten
>
> Thorsten
Re: Jena release : suggested approach
Posted by Thorsten Möller <th...@unibas.ch>.
Am 30.11.2011 um 17:26 schrieb Paolo Castagna:
> Thorsten Möller wrote:
>> Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
>>
>>> == Version number
>>>
>>> I think it's worth bumping the minor version number on ARQ and Jena - the jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL 1.1 (query, update) complete.
>>>
>>> JenaTop 0
>>> IRI 0.9.0
>>> Jena 2.7.0
>>> ARQ 2.9.0
>>> LARQ?
>>> Download 2.7.0 (in line with Jena core)
>>
>> Does it mean version numbers of the download and Jena-core are kept in line just for this release or also for future releases? What if you want to release a new download (because of a critical bug in a non Jena-core module) while the version of Jena-core has not changed - fourth level 2.7.0.1?
>
> Hi Thorsten,
> I am not sure I completely understand your question.
>
> But, let's say a critical bug is found in jena-core 2.7.0.
That's the innocuous case. Suppose the initial versions are Jena-Core 2.7.0 and 2.9.0 for ARQ. Then a critical bug is found and fixed in ARQ, a new release of ARQ is made having a new version number, say 2.9.0->2.9.1, and you want to provide a new/updated download. Then you either have the option of increasing the version of the download, say 2.7.0->2.7.1, which results in tying it apart from Jena core. Or you introduce a fourth level for the download 2.7.0.1, thereby keeping the first three levels in line with Jena core.
Thorsten
Re: Jena release : suggested approach
Posted by Paolo Castagna <ca...@googlemail.com>.
Thorsten Möller wrote:
> Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
>
>> == Version number
>>
>> I think it's worth bumping the minor version number on ARQ and Jena - the jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL 1.1 (query, update) complete.
>>
>> JenaTop 0
>> IRI 0.9.0
>> Jena 2.7.0
>> ARQ 2.9.0
>> LARQ?
>> Download 2.7.0 (in line with Jena core)
>
> Does it mean version numbers of the download and Jena-core are kept in line just for this release or also for future releases? What if you want to release a new download (because of a critical bug in a non Jena-core module) while the version of Jena-core has not changed - fourth level 2.7.0.1?
Hi Thorsten,
I am not sure I completely understand your question.
But, let's say a critical bug is found in jena-core 2.7.0.
We can fix it there and release: jena-core 2.7.1.
And then decide to roll-out a new Jena download (a.k.a. apache-jena 2.7.1).
Why do you think a fourth-level version number is necessary?
Cheers,
Paolo
>
> Thorsten
Re: Jena release : suggested approach
Posted by Thorsten Möller <th...@unibas.ch>.
Am 30.11.2011 um 10:39 schrieb Andy Seaborne:
> == Version number
>
> I think it's worth bumping the minor version number on ARQ and Jena - the jar files have changed name format; the maven artifacts have different names, ARQ is SPARQL 1.1 (query, update) complete.
>
> JenaTop 0
> IRI 0.9.0
> Jena 2.7.0
> ARQ 2.9.0
> LARQ?
> Download 2.7.0 (in line with Jena core)
Does it mean version numbers of the download and Jena-core are kept in line just for this release or also for future releases? What if you want to release a new download (because of a critical bug in a non Jena-core module) while the version of Jena-core has not changed - fourth level 2.7.0.1?
Thorsten