Junit [LSARC/2008/633 FastTrack timeout 10/21/2008]

[Lloyd Chambers]

IMO, it is unacceptable to overwrite the old version.

Software development does not work that way: you want specific  
versions and you do not want a new one appearing randomly to cause new  
problems.

If it's maven-based, then the problem is solved (see my previous  
message).  If not, I would never create a build system that assumed  
some installed version would be the right one; I'd commit the needed  
version into my source code/build repository eg svn or cvs.

Lloyd

..............................................
Lloyd Chambers
lloyd.chambers at sun.com
GlassFish team, LSARC member

On Oct 21, 2008, at 1:33 PM, John Plocher wrote:

> Jim Walker wrote:
>> We also understand the problem where several open source projects  
>> depend
>> on older versions of Junit and don't plan to update their code to use
>> the newer version. We felt it was best to start by porting the  
>> current
>> version and revise it as new releases are made available. Then,  
>> look at
>> adding additional older versions that are frequently used/requested.
>
> There needs to be something about how you intend to handle these
> newer versions.  The canonical choices are:
>
> 1) overwrite the old version with the new, thus only having one
>   installed at any given time, or
>
> 2) have some directory structure/pkg architecture to support the
>   unambiguous installation and use of multiple versions on a
>   single system simultaneously
>
> If 1, why are you doing something that isn't well aligned with
> the known use-case for the component, and if 2, how will you
> actually do it?
>
>  -John
>
>