Releases

[Andy Seaborne <an...@apache.org>]

JENA-190 "Jena delivery"
JENA-191 "Jena module structure and build"

We're planning on having a multi-module/single-version build right?

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.

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.

"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.

Re: Releases

[Paolo Castagna <ca...@googlemail.com>]

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.

Yep.

>> 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.

Ack.

Paolo

> 
>     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.
>