"Steve" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > >> -----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. >
Actually, the reason Gump came into being is because of incompatible version changes :). What it does is let other projects know that this is happening early enough that they can plan how they want to deal with it. A fair number of times, it's to switch from project foobar to project packaged-foobar, and deal with it later. But at least it's on their radar now :). It might be a nice feature to be able to create a packaged-foobar just from the metadata, without having to get Stefen involved with downloading the jars himself. Maybe something for Gump 3. > 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. > You can do that now: Just create a foobar-v1.xml that builds off a branch instead of HEAD, and depend on that. > Cheers, Steve. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
