Seems indeed a process that should be possible to automate for
release. I agree with Juris that doing this manually at each release
is asking for trouble. It's too easy for one to slip through without
being updated properly.
I have another question though (not sure if this has been covered
already). Imho we should always replace the -SNAPSHOT suffixes, even
when nightly builds are made. Otherwise, people will never be able to
automatically upgrade between snapshots. So, -SNAPSHOT should ideally
be replaced by the SVN revision number and some prefix/suffix
indicating that this is a nightly build. Thinking further along those
lines, I'm wondering if the version dependencies shouldn't be a bit
more flexible. Depending on exact versions is frustrating since it
means that all references will always have to be updated when newer
releases come out. I'm not sure what the possibilities are, and if
the required information is available through Maven repositories, but
I think that it might be interesting to be able to do something like
this:
>=2.0.3
foo 2.0.3 or later
=2.0*
any foo 2.0.x
<=2.0.2
foo 2.0.2 or previous
=2.0.1
foo 2.0.1 exactly
On 26 Sep 2007, at 00:57, Alex Miller wrote:
> Automate!
>
> ----- Original Message -----
> From: "Juris Galang" <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, September 25, 2007 5:52:46 PM (GMT-0600) America/
> Chicago
> Subject: Re: [tc-dev] versions and modules
>
> Because we have to scan for references to SNAPSHOTs each time we have
> to do a release. People are bound to forget.
>
> On Sep 25, 2007, at 3:44 PM, Steven Harris wrote:
>
>> It won't be all modules. only the ones that have changed. A released
>> module should
>> have no dependencies on snapshots. Why do you think it is iffy?
>>
>> On Sep 25, 2007, at 3:33 PM, Juris Galang wrote:
>>
>>> Feels kinda iffy that we have to go through and un-SNAPSHOT our
>>> modules every release/code-freeze time.
>>>
>>> We could bring back the snapshot repository to simplify things; but
>>> that would mean we'd be locked in a mode where the user is either
>>> working with snapshots or not - though I think this might not be a
>>> bad thing;
>>>
>>> Eugene pointed out however that some users could find it useful to
>>> mix-and-match --- question is: would this be the more common use
>>> case?
>>>
>>>
>>>
>>> On Sep 25, 2007, at 2:09 PM, Eugene Kuleshov wrote:
>>>
>>>> Hi,
>>>>
>>>> I had somehow lengthy discussion with Juris about config modules,
>>>> versions and dependency resolution.
>>>>
>>>> Recently added default modules that are specified in
>>>> tc.properties
>>>> made whole picture little more messy, especially if take Maven into
>>>> the
>>>> equation.
>>>>
>>>> To summarize, DSO configuration modules that are used at runtime
>>>> can
>>>> come from several places:
>>>>
>>>> -- l1.configbundles.default entry in tc.properties:
>>>> l1.configbundles.default =
>>>> excludes-config;guimodels-config;jdk15-preinst-config;spring-
>>>> config;standard-config
>>>>
>>>> -- modules declared in tc-config.xml
>>>> <modules>
>>>> <module name="clustered-ehcache-1.3" version="1.0.0"/>
>>>> </modules>
>>>>
>>>> -- transitive dependencies listed in manifest.mf of any other
>>>> module.
>>>> Foe example for clustered-hibernate-3.1.2 we currently have:
>>>> Bundle-SymbolicName: org.terracotta.modules.clustered-
>>>> hibernate-3.1.2
>>>> Bundle-Version: 1.0.0
>>>> Require-Bundle: org.terracotta.modules.modules_common,
>>>> org.terracotta.modules.clustered-cglib-2.1.3
>>>>
>>>> If you think about above examples, they leave lots of assumptions
>>>> about what modules versions should be used and it could lead to
>>>> some
>>>> nasty issues at the runtime.
>>>>
>>>> For some reason I thought it been agreed that we should always
>>>> explicitly specify all versions and also use -SNAPSHOTS between
>>>> releases, but it doesn't seem like it been changed in existing
>>>> modules,
>>>> except that tcbuild is adding -SNAPSHOT suffix to the nightly build
>>>> jars
>>>> deployed to maven repo.
>>>>
>>>> So, above configuration snippets should be changed as the
>>>> following:
>>>>
>>>> l1.configbundles.default =
>>>> excludes-config,1.0.0-SNAPSHOT;guimodels-config,1.0.0-
>>>> SNAPSHOT;jdk15-preinst-config,1.0.0-SNAPSHOT;spring-config,1.0.0-
>>>> SNAPSHOT;standard-config,1.0.0-SNAPSHOT
>>>>
>>>> Bundle-SymbolicName: org.terracotta.modules.clustered-
>>>> hibernate-3.1.2
>>>> Bundle-Version: 1.0.0-SNAPSHOT
>>>> Require-Bundle:
>>>> org.terracotta.modules.modules_common;bundle-
>>>> version="1.0.0.SNAPSHOT",
>>>>
>>>> org.terracotta.modules.clustered-cglib-2.1.3;bundle-
>>>> version="1.0.0.SNAPSHOT"
>>>>
>>>> note that we can't use "-" for SNAPSHOT suffix in the bundle
>>>> version,
>>>> because OSGi prohibits that, so we may need some mapping in our
>>>> module
>>>> jar resolver code.
>>>>
>>>> Then at release/code freeze time someone will have to do a quite
>>>> verbose operation and change all those versions to the release
>>>> versions.
>>>>
>>>> Any thoughts?
>>>>
>>>> regards,
>>>> Eugene
>>>>
>>>>
>>>> _______________________________________________
>>>> tc-dev mailing list
>>>> [email protected]
>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>
>>> _______________________________________________
>>> tc-dev mailing list
>>> [email protected]
>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>
>> _______________________________________________
>> tc-dev mailing list
>> [email protected]
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>
> _______________________________________________
> tc-dev mailing list
> [email protected]
> http://lists.terracotta.org/mailman/listinfo/tc-dev
>
> _______________________________________________
> tc-dev mailing list
> [email protected]
> http://lists.terracotta.org/mailman/listinfo/tc-dev
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
