incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Releases
Date Mon, 12 Mar 2012 20:46:19 GMT
Hi Andy

Andy Seaborne wrote:
> JENA-190 "Jena delivery"
> JENA-191 "Jena module structure and build"
> We're planning on having a multi-module/single-version build right?

JENA-191 says: "maybe we should have a single trunk, multi-module, single
source-release, single version number build for Jena."

This seems to me a good evolution from where we are, it can simplify the
release process and lower the cost of managing multiple modules or adding
a new one. But, I'd like to hear the opinions of others, if they have a
different proposal or a better approach to manage the project.

Comments on JENA-191 are around single trunk (where it seems there is
definite agreement) and multi-module (ditto).

I didn't read much feedback on the single source-release bit or the
single version number. Do they follow from the multi-module /
single-version decision, given the constraints and limitations of
tools and environment?

> We are where we are today because of history; modules have been
> developing at different speeds.  Users of Jena and ARQ don't need to see
> every increment to TDB as it grew from first release to full system.

Yes, this would be a problem with single version number and a release
process which releases all modules at the same time.

> A single consolidated release has advantage and disadvantages.  A
> downside is how to distribute bug fixes for one part of the system for
> users so they don't need to do more than verify the fix.  A
> too-frequently changing version number for the whole system isn't
> helpful to solid, stable parts of Jena.  That might be a cost we (all)
> just have to accept.

Yep. However, users can chose not to upgrade, until they have a reason
to do so. For example, if there is a bug fix release in a module that a
user isn't using he/she might decide to wait and not upgrade. Bug fix
releases, IMHO, should be fully backward compatible and upgrading should
be just a drop-in replacement. If this is true, upgrading after a bug
fix release, can be very cheap for users.

Another problem or disadvantage of a single source-release and single
version project is that if you need to produce a bug fix release for a
module and there is another module which is not ready to be released
that would be a blocker for the bug to be fixed. To avoid this sort of
issue, people, use different approaches. One approach is: trunk should
always be releasable (which is already often true for most of the modules
we have. But, there might be times where this isn't true).

> "release often" is OK it's one thing so "release early, release often"
> makes good sense as "early" probably means it's one thing or at least
> all changing together.
> If it's treated as several subparts (as you want for custom setup like
> just parsers), the subparts may be have conflicting needs for release
> cycles.


>> What are in your opinion pros/cons (technical and non) in relation to
>> releasing one module at the time (i.e. multiple [VOTE]s) vs. release
>> all modules in one shot (i.e. one [VOTE])?
> We have had multiple releases; it seemed the quickest way to graduate
> and also get stuff to users.  I'm sorry TDB took several attempts.  I'm
> aware it is tiring on the project.



>     Andy
> On 08/03/12 09:28, Paolo Castagna wrote:
>> Hi,
>> this is what I wrote two or three times in the last few weeks (and
>> deleted it):
>> "I don't want to start and endless discussion now, but at some point
>> we should discuss pros/cons of multi-module projects (such as Apache
>> Jena) which wants (or needs?) to release single modules
>> independently (while in incubation). (It seems to me there are more
>> cons in what we are doing than pros and maybe this is the reason why
>> many other incubating (and multi-module) projects don't do it
>> like us (i.e. they go for a single version and release all the modules
>> at the same time == 1 vote)."
>> What are in your opinion pros/cons (technical and non) in relation to
>> releasing one module at the time (i.e. multiple [VOTE]s) vs. release
>> all modules in one shot (i.e. one [VOTE])?
>> Why are we (I am probably less attached than others (*)) so attached
>> to the "one module at the time"? History? Technical reasons?
>>  (*) indeed in the office I do/advice for exactly the opposite as we
>> do here: a multi-module project (when necessary/useful) --> single
>> version number for all the modules --> release everything in one
>> shot --> release often, no problem --> version _._.x+1 == drop-in
>> replacement (i.e. often a bug fix release, no new functionalities...
>> certainly, no backward incompatible changes).
>> My intention here is not to be critic or cause a flaming and endless
>> discussion, if this is what's going to happen, I will simply shut up
>> and let time to fix/settle things (slowly). I can wait.
>> Paolo
>> PS:
>> I wrote something similar to this two or three times (and deleted it).
>> Maybe I should have sent it on general@i.a.o, maybe it was the right
>> choice not to send it (while the vote for TDB is still
>> running), maybe I should not have sent this message... but this time I
>> hit send instead of delete.

View raw message