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
