Welcome to the BEAM Forum!

We encourage you to sign in our forum and participate in the BEAM community. The forum is maintained by the BEAM project team who will most likely answer your questions within 24 hours (except during common holidays) - if not done by other community members. Collaborate, share your knowledge and learn from other users!

If you don't find what you are looking for, please also consider the following external forums:

Combination View Flat View Tree View
Threads [ Previous | Next ]
Modules version numbers: what about a unified version?
toggle
Hi,
sorry if I'm bothering you with a lot of question these days.
I really like BEAM and I'm going to use it again to do some processing.
I'm using code from GIT, master branch.
When importing it on eclipse or creating jar artifacts I have noticed that several modules declare different versions.
So there is:

5.0
beam-aatsr-sst-5.0.jar
beam-alos-reader-5.0.jar
beam-atsr-reader-5.0.jar
beam-bootstrap-5.0.jar
beam-chris-reader-5.0.jar
beam-csv-dataio-5.0.jar
beam-envi-reader-5.0.jar
beam-examples-5.0.jar
beam-getasse30-reader-5.0.jar
beam-hdf5-writer-5.0.jar
beam-meris-cloud-5.0.jar
beam-merisl3-reader-5.0.jar
beam-ndvi-5.0.jar
beam-opendap-5.0.jar
beam-pconvert-5.0.jar
beam-pgx-reader-5.0.jar
beam-pixel-extraction-5.0.jar
beam-rtp-codec-5.0.jar
beam-scripting-5.0.jar
beam-spot-vgt-reader-5.0.jar
beam-statistics-op-5.0.jar
beam-temporal-percentile-op-5.0.jar
beam-time-series-tool-5.0.jar
beam-unmix-5.0.jar
beam-visat-5.0.jar

5.0.1
beam-bigtiff-5.0.1.jar
beam-cluster-analysis-5.0.1.jar
beam-envisat-reader-5.0.1.jar
beam-flhmci-5.0.1.jar
beam-geotiff-5.0.1.jar
beam-meris-smac-5.0.1.jar
beam-modis-reader-5.0.1.jar
beam-obpg-reader-5.0.1.jar
beam-reader-tests-5.0.1.jar

5.0.2
beam-collocation-5.0.2.jar
beam-ui-5.0.2.jar

5.0.3
beam-avhrr-reader-5.0.3.jar
beam-meris-radiometry-5.0.3.jar

5.0.4
beam-visat-rcp-5.0.4.jar

5.0.5
beam-core-5.0.5.jar
beam-python-5.0.5.jar

5.0.7
beam-landsat-reader-5.0.7.jar

5.0.8
beam-landsat-reader-5.0.8.jar

5.0.X-SNAPSHOT
beam-binning-5.0.8-SNAPSHOT.jar
beam-gpf-5.0.7-SNAPSHOT.jar
beam-proba-v-reader-5.0.2-SNAPSHOT.jar

Is it made on purpose? (As an instance your intention is to not increase the version of a module until important changes occur on it)
Or is it simply a set of typo/oversights instead?
Do you think it would make sense to unify the versioning by updating all of them to a 5.0-SNAPSHOT (or whatever you prefer), or do you think that this would complicate your current release process and versioning system (which I'm unaware of)?

If you agree with my suggestion to switch to an unique version number, I can provide some help with a pull request to github.
Please, let me know.

Best Regards,
Daniele
Flag Flag
RE: Modules version numbers: what about a unified version?
4/14/16 9:03 AM as a reply to Daniele Romagnoli.
The versioning is by intention. The version is only incremented if the module is changed.
In SNAP we have a common versioning.

best wishes
Marco
Flag Flag