Seems there is some misunderstanding here, I agree in many things you
said, extend version schemas, allow different schemas to be pluggable
if possible, set a default schema as "standard",...
I'd just prefer have xml syntax over string parsing and encourage
people to use whatever the standard we choose.
On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
>> Carlos Sanchez wrote:
>> > the repository has some rules and you have to follow them to be
>> > manageable, eg. you name jars artifactId-version.jar and not
>> > otherwise. If there are version rules you'd have to follow, and I
>> > don't see the problem in having a standardized version convention, as
>> > we have standardized folder names.
>>
>> As I said before:
>>
>> > The problem is basically that this simply isn't powerful enough to
>> > cover all the various versioning schemes there are in the wild.
>
> 4 or more sections will cover almost all the versioning schemas
What sections?
If you're talking about the 4 sub-elements of the pom, why limit to 4?
We've got a good solution now that allows for any number of 'sections'.
>> > Suggesting forcing everybody to conform to your idea of versioning
>> > isn't at all helpful; similarly imposing a complex mapping between
>> > upstream and maven versions for a project is unattractive.
>
> projects shouldn't care and will end benefiting from standardization
> as they did with folder names. We need to look to other versioning
> standards out there (eg. OSGi) instead of inventing a new one.
> if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
> we can sort the sections
Folder names? For what?
Where would you use 1/0/alpha/1?
I'm pro standardization, and we should set an example, but I disagree that we
should limit
or enforce our version scheme to OSGi or any other schemes out there. This will
limit the
applicability of maven in the field. It should be 'convention over
configuration', meaning that
if you follow 'our' standards, it's easy; if you have other company policies,
you should be able to
apply them to maven aswell.
We could adopt the OSGi versioning scheme when developing maven (although we
already have one
which is pretty similar), but I do not want to impose that on maven users.
I'm finding that you're the only one objecting somewhat, and can't find a real
reason or usecase
that contradicts my proposal in any way. All I'm suggesting is that we replace
the version
implementation with something that's more flexible, backwards compatible, and
can be used for any
known scheme. I'm just asking for usecases where the solution won't work.
Extending the POM to add configuration for custom version schemes is another
(though related)
discussion, and can be added later on, though I doubt if it's necessary.
-- Kenney
>
>>
>> Which part do you disagree with?
>>
>>
>> --
>> Richard van der Hoff <[EMAIL PROTECTED]>
>> Telephony Gateways Project Manager
>> Tel: +44 (0) 845 666 7778
>> http://www.mxtelecom.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
