> -----Original Message-----
> From: Steve [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 19 February 2006 3:32 AM
> To: 'Gump code and data'
> Subject: RE: Upgraded vmgump to JDK 1.5
>
>
>
> > -----Original Message-----
> > From: Leo Simons [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, 19 February 2006 2:46 AM
> > To: Gump code and data
> > Subject: Re: Upgraded vmgump to JDK 1.5
> >
> > This is to "solve" the junit stuff right?
> >
> > Will be interesting...I'm personally not happy with how effectively
> > there's this one project run by a bunch of people who don't
> > particulary understand enough about backwards compatibility and the
> > like (just like Sun really) which force this kind of thing.
>
> It's not like 'that bunch of people' are taking away 3.8.1!
> Products evolve and there is a well established convention
> concerning major version increments. The JUnit team are
> working of 4.X - and that means they are working on a new
> product that is not compatible with the 3.X line.
>
> This is a trend commonly referred to as "progress".
>
> > The stupidness is that this is in part a limitation that gump has.
>
> Yes - which is the relevant subject for this list.
> Subscribers should not be moaning about the fact that an
> independent project is going the next step and building an
> even better testing framework - instead, subscribers should
> be looking at why this is an issue for Gump.
IMO - the issue is that Gump project descriptors do not include a definition
a major version identifier and the underlying support that this implies
within respect to dependent builds (i.e. group/name is not sufficient). The
absence of this creates a scenario where the assumption is that incompatible
version changes are not recognized as a technical reality.
This in-turn creates an inconsistency between:
(a) the role of Gump as a technical community integrity checker
(b) the decisions of a particular project/group concerning product
evolution
My suggestion would be to consider every Gump project as an implicit version
0 and enable an explicit major version identifier. From this consumer
projects would be able to lock onto the assumed major version without fear
of disruption from source project major-version evolution.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
