Niclas Hedhman wrote:

On Monday 05 April 2004 21:27, Berin Loritsch wrote:


Hmm. The seeming product fragmentation would seem to present a problem as
far as confusing users.  For example, the user has to know that Merlin CLI
version 3.2.* will work with Merlin Model 3.4.*, but not Merlin Model
3.0.*, etc.


This was the reason why I brought it up.
But at the same time I understand Stephen's reasoning as well, which is purely from a technical viewpoint.

<snip/>


As Stephen points out, there are more than one problem at hand here. The reason why I brought it up, is because we are already getting a chaos inside Merlin of the internal dependencies, and to 'bump' the version is a difficult and error-prone task that needs to be automated. The quickest and simplest solution that could work was to unify the Merlin versions under a single point (the root POM).

The problem still remains though, we semi-internal and external dependencies, so the conclusion is that a version handling framework is need "anyway", and the management aspect of unified numbers may drop from the agenda.

I am still split in the question, slightly in favor of a unified numbering.

Ok. I was kind of thinking of doing it like applying a label in CVS. Any one file can have several labels. In essence, any one "product" (there are no products in OSS, but it is the easiest way of referring to it) would have several versions--hense still satisfying both needs.

It might be hairbrained, which is why I am not adamant about it at all.  I do
agree that something as simple as version increases should not be so difficult
or error prone.  That would be very bad.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to