On Dec 4, 2006, at 1:57 PM, Paul McMahan wrote:
Yes they are new specs. I used 1.1-SNAPSHOT because the spec I was
using as a template (geronimo-servlet_2.5_spec) started with that
version number. Wish I had poked around a little more and I would
have realized.
No worries... not picking on you, just happened to notice this in
your change.
Really, if we are going to version these modules separately, then
they should start at 1.0-SNAPSHOT. If we version the entire project
together, then its obviously fine to add new modules when the version
is not 1.0*
But until we collectively see that light... :-P... lets use
consistent and logical versioning for these modules. Skipping
versions is just going to confuse people.
I agree but unfortunately I have already published to the snapshot
repo using 1.1-SNAPSHOT. Should I address your concern by manually
deleting them from the repo and republishing them as 1.0-SNAPSHOT? Or
would that be overkill? I'm fine either way.
BTW, there are some other specs in there that also did not start at
1.0-SNAPSHOT (at least not published in this repo):
- geronimo-corba_3.0_spec
- geronimo-servlet_2.5_spec
- geronimo-spec-corba
- geronimo-ws-metadata_2.0_spec
Maybe its too late for those(?)
Well, this is going to be an ongoing problem with using per-module
versions for these.
Seem fairly obvious to me if you are creating a new module, copied
from another or not, that you should always change the version, name,
artifactId of the module.
Anyways... if these were only published as snaps, then I would remove
the artifacts from the m2-snapshot-repository, update the poms with
1.0-SNAPSHOT, update deps, and then redeploy.
* * *
I still recommend using one version for all specs though... then all
this version muck basically goes away. This may be more and more
important as I get more stuff automated, as its not really easy to
ensure that code put into specs will actually be used by a dependency
project. So its hard to say if specs/trunk is compatible with server/
trunk with any degree of certainty... I would normally expect that
they would be compatible... but Maven's remote repo/dependency muck
(plague in disguise) really does more to promote build instability
than to allow codeline consistency.
--jason
