Hi Brian,
On Apr 5, 2005, at 6:11 PM, Brian Topping wrote:
>
>
> Craig Russell wrote:
>
>> Hi Michael,
>>
>> On Apr 5, 2005, at 12:47 PM, Michael Bouschen wrote:
>>
>>> Hi,
>>>
>>> today the jdo project api11 and api20 use the same artifactId
>>> 'jdo-api', but different version numbers (1.1 vs. 2.0). I think
>>> both projects should not share the same artifactId. They implement
>>> the JDO API as defined in different specs: JDO1 (JSR-12) and JDO2
>>> (JSR-243), so they should coexists. I propose to change the
>>> artifactId to jdo1-api and jdo2-api and do a similar change for
>>> ri11, tck11 and tck20.
>>
>>
>> Sounds good.
>
> +1. Just ran into this myself.
>
>>>
>>> Another question: the maven doc for the currentVersion project
>>> descriptor element says: "The current version of the project. This
>>> should end in -SNAPSHOT until the release of that version is made.".
>>> I propose to add the '-SNAPSHOT' in the project.xml of the jdo
>>> projects.
>>
>>
>> If this is really what other projects do, I'd agree. Do any of you on
>> this alias have experience with other projects using the -SNAPSHOT
>> suffix? I assume that this means that the name of the jar is for
>> example jdo2-api-2.0-SNAPSHOT until we release.
>
> There's a lot of dragons lurking in this area. One of the ones that I
> have had a lot of problems with are projects that include the -SNAPSHOT
> suffix in the <version/>. I would advocate that this is the wrong way
> to do it because it breaks all the snapshot and release tools that are
> built into maven itself.
>
> Dentaku, XDoclet2, Mule, and all my internal projects use the
> jar:install-snapshot goal as the default goal, which automatically adds
> the suffix. What's nice is that 'jar:snapshot-deploy' (for those with
> correct privs) will push the jar from your repo to the correct staging
> area for pushing to Ibiblio, without per-user files that need to be
> modified in the RCS areas. There are similar goals for released
> version
> pushes.
>
> When used like this, there is no version number in the SNAPSHOT name,
> i.e. 'jdo2-api-SNAPSHOT.jar'. I agree that this is the correct
> behavior, since developers who want to be on the bleeding edge and
> always get the latest should not have to change the name of their
> dependencies if there are releases on projects (thus changing the
> version numbers).
I think I understand this, and agree. I'm keen on having the discussion
on binary releases now that we are at a point in both projects where a
release makes sense.
I think the api11 is ready today for alpha; ri11 is ready if we can
skip upgrading the enhancer to handle J5 classes; tck11 is ready today.
I think api20 is ready today for a SNAPSHOT; might need a vote whether
it's ready for an alpha. I don't think tck20 is ready for alpha; does
it need anything special for a snapshot?
Craig
>
>>
>> Does release mean an alpha or beta? So when we decide that the api is
>> ready for external use (I actually think we've made that decision
>> already) that we would name it jdo2-api-2.0-ALPHA1, or less loudly,
>> jdo2-api-2.0-alpha1.
>
> Might want to look through the jars on Ibiblio for this one, most
> people
> just use (for instance) jdo2-api-2.0a1.
>
> Is there a definitive release nomenclature on this project yet? Any
> links if so?
>
> :b
>
>>
>> Craig
>>
>>>
>>> What do you think?
>>>
>>> Regards Michael
>>>
>>> --
>>> Michael Bouschen Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33 Buelowstr. 66
>>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
|