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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
