Yea… using the “_” separator would work. We couldn’t do a “.”, but a
separator could work to denote the “version” from servicemix.
Dan
On Jan 4, 2018, at 12:04 PM, Jean-Baptiste Onofré <[email protected]>
wrote:
That could work but we need to extend the version with a specific
iteration.
For instance servicemix-specs-jaxrs-api-2.1 could be
servicemix-specs-jaxrs-api-2.1_1 (for instance, we can imagine to have a
new fix/builds on the same spec version). It's the same format as in the
bundles.
Regards
JB
On 01/04/2018 05:26 PM, Francois Papon wrote:
Hi,
I think it's a very good idea.
Just for my curiosity, why not use the specification version in the
release ?
For example, in servicemix-specs-2.9.0, the jaxrs-api version is 2.1,
may be it would be easier to check if the new release will be
servicemix-specs-jaxrs-api-2.1 ?
And to release a fix version we could add a last number in the version.
François
Le 04/01/2018 à 19:49, Daniel Kulp a écrit :
I definitely agree with this. The last thing I needed from specs
was JUST a new jax-rs bundle so I did just do a release of just that
bundle. However, with the build setup for monolithic releases, it was
harder than it should be. It would be great to get the poms and such
setup so we could just release the individual specs that change.
One question would be around version number - the last “full release”
was 2.9.0. For updates to current specs, do we jump to 3.0? For brand
new specs, would we start at 3.0 or start at 1.0 like we do in bundles?
Dan
On Jan 4, 2018, at 10:32 AM, Jean-Baptiste Onofré <[email protected]>
wrote:
Hi guys,
Up to now, we did monolithic ServiceMix Spec release (all spec in a
row).
As the spec are very stable, it's really painful to do a full specs
release when a did a minor update or fix on a single spec.
As we do for the bundles, I propose to change ServiceMix Specs in
order to be able to release atomic spec.
Thoughts ?
If you agree, I will prepare the change.
Thanks,
Regards
JB
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
