river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Graduation - Was Re: Praise for River Development team
Date Mon, 15 Nov 2010 09:44:19 GMT
Segmenting the JARs and changing the namespaces are two very big
chunks of work.  Both of which are going to have an impact on our
users.  (Let's not forget the user list!)

Moving the package names would be a nice to thing to do for
graduation.  It just feels more clean.  If there is real fundamental
reason why to leave it until afterwards, then I'm not going to argue
the point.  I would think that segmenting (and maven-izing, maybe) the
build can wait until after graduation.

This would be my preferred roadmap;

1. Bug fix release (minor version number change)
2a. Namespace change release (major version number change)
2b. Graduate
3. Segment build release (major version number change)

I see 2b as being our "graduation build".

My reluctance to spread the namespace change over a number of builds
is simply due to the work we then place on our users.  If, after each
release, they need to refactor and/or retest their own code (which
might be an extensive task) then asking them to do that multiple times
is a big ask.  Warning them that in X months times, if they want to
continue using River, they're going to have to go through one big hit
of pain is (in my perhaps flawed opinion) a better approach.

Having said that, I can see Peter's point that because of the scale
and impact of the task, taking it slowly and carefully is an
attractive approach.

My gut still says that a warning and big bang approach would be
cleaner (especially if it coincides with graduation).  However, I've
also learnt not to accept advice from many of my own body parts...

On Mon, Nov 15, 2010 at 8:36 AM, Sim IJskes - QCG <sim@qcg.nl> wrote:
> On 15-11-10 09:04, Peter Firmstone wrote:
>>
>> Some thoughts:
>>
>> I think we could move service implementations and proxy's first, client
>> code should not directly depend on these and it moves large quantity of
>> code to the new name space.
>>
>> Due to the size of the task of moving all of com.sun.* and the potential
>> implications, I think we should take a softly softly approach, this
>> might take a number of releases.
>>
>> As we rebuild the namespace we could make it more modular as we progress.
>
> My proposal is the exact opposite. Just do it on the current codebase in one
> go, and not add extra constraints to it. From a code perspective it is a
> trivial excercise. Any problems i've experienced with it, were tool
> breakdown, and files outside the scope of the 'refactoring engine'.
>
> If we are all in agreement, we should merge the stuff we want included, and
> then make the svn jtsk trunk single user commit.
>
> As i've promised before i became committer i will try to do the package
> rename in the code and svn, but we have to have plans for the secundary
> stage (i.e. text files containing package references).
>
> For the first stage we need to establish the following rules:
> - move files with their revision history intact. (svn move = svn copy, svn
> delete)
> - only commit after codebase compiles.
>
> The following steps are to be defined.
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>

Mime
View raw message