search

ome / ome-model

OME model (specification, code generator, implementation)
Other
13 stars 26 forks source link

build: Unify component version property names #69

Closed rleigh-codelibre closed 6 years ago

rleigh-codelibre commented 6 years ago

This is to allow -Dome-common.version=... or rewriting the configuration to work the same for all components. This one was different for some reason.

Testing: check builds are green.

rleigh-codelibre commented 6 years ago

Green in https://web-proxy.openmicroscopy.org/east-ci/job/BIOFORMATS-merge/20/

rleigh-codelibre commented 6 years ago

I don't think it matters that much, it's not something that an end user would have any need or reason to override; until now we haven't even had a reason to do this ourselves. But if you think it's necessary, I can create a compatibility variable.

joshmoore commented 6 years ago

@rleigh-codelibre : not knowing who's consumed this over the last year can I suggest we get the alias added here along with a deprecated comment and then merge this along with https://github.com/ome/ome-poi/pull/6 and https://github.com/ome/ome-codecs/pull/10?

In terms of the release, it might be a "nice-to-have" at least to show that someone else can still go through the steps. But with other upcoming changes, perhaps now isn't the right time?

joshmoore commented 6 years ago

@rleigh-codelibre : do you have a commit coming for this?

rleigh-codelibre commented 6 years ago

Done.

Do we have a policy for deprecation and removals in the build systems?

I don't really consider this "API" myself. It's developer-only build scripts which by their nature can change, and without impact on the real API in the jars. No one will encounter this unless building from source, and even then only if they are deliberately tampering with the properties, in which case it requires some effort on their part to keep track of changes in the poms. I hope we can drop this sooner rather than later.

sbesson commented 6 years ago

No formal policy and I would also rank build system changes as having less impact than API changes in general e.g. here the addition of a build property would be fine as a patch release from my side. Re property deprecation, aliasing is probably the closest we have although there might be formal ways to do so.

Regarding developer stability, my understanding of this ongoing work is that we are effectively establishing a stable scheme for property names across our set of Maven components. Effectively, we are not expecting subsequent changes to these property names outside the context of other major changes like component renaming or build system overhaul.

joshmoore commented 6 years ago

Thanks both. I'll leave you guys to capture when/how we want to remove the compatibility layer.

Merging as per https://github.com/ome/ome-codecs/pull/10#issuecomment-370461418 for a patch bump.