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 [email protected], 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. >
