Return to Answer

• Pull the source code from 1/N repositories and from specific branches.
• Build the root project (non-recursive)
• Build all the modules or just a pre-selected one.
• Test the module/s
• Package the candidate artifact to be distributed, with the required modules/versions.
• Test the package (as a whole)
• Push one or all the binaries to the artifact repository.

1. Pull the source code from 1/N repositories and from specific branches.
2. Build the root project (non-recursive)
3. Build all the modules or just a pre-selected one.
4. Test the module/s
5. Package the candidate artifact to be distributed, with the required modules/versions.
6. Test the package (as a whole)
7. Push one or all the binaries to the artifact repository.

What I want to do is keep offering releases for the individual modules, because it makes updating much easier. (Bugfix release? just exchange the jar file). But I always want to release distribution packages.

I think you are coupling (virtually) different things related with the SDLC; source code management, packaging and distribution.

If the source code is under the umbrella of one repository or many should be irrelevant for its packaging and distribution.

Regardless the number of repositories and the version strategy involved, It should be possible for you to set a pipeline so that

• Pull the source code from 1/N repositories and from specific branches.
• Build the root project (non-recursive)
• Build all the modules or just a pre-selected one.
• Test the module/s
• Package the candidate artifact to be distributed, with the required modules/versions.
• Test the package (as a whole)
• Push one or all the binaries to the artifact repository.

Repeat #4 as many times as versions you need to prove compatibility with. It might involve repeating #1,#2 and #3 with different branches or download the existing binaries from the artifact repository.

Repeat #5 for every package in #4.

This should be possible regardless the version strategy because versions are tracked by the SCM (branches, tags, whatever) or by the artifact repository.

Under these circumstances - what is the meaning of the version number of the maven root project?

Only the one you need to provide with.

If the root project is mean to be integrable, keep the Semantic Version because is useful for consumers. You have to decide what changes on the modules cause the root project's version to change and how. That's up to you, we can't tell given the little context we have.

If not or if it's causing confusion, then change it.

Think in Android. Android is distributed following a different version strategy than the components or services It comprises.

I run Android A but the GBoard is x.y.z. There could be several patches but it's still A. There have been a couple of releases of GBoard since I installed Android A. I have installed both versions but my Android version remains the same.

Internally, Google probably follows a second strategy to track the different patched versions of Android A. Which one, I don't know. Probably one involving build dates and numbers.

What version should the distribution package have?

I don't think you are asking to the right audience.

I feel like a date-based approach might be better suited here. Make a distribution release every 6 months or so and call it 2020_06. If an important bugfix required the update of a component in between, a version like 2020_06.2 might work as well.

This answers your previous question. Note that you set the semantics according to one prupose, tracking versions and updates on the time. You sret basically explaining that

• There will be a different version the next year
• There could be up to 1 revision per month.
• There could be one or more updates this month

If that's what you want me to know, then seems fine.

What I want to do is keep offering releases for the individual modules, because it makes updating much easier. (Bugfix release? just exchange the jar file). But I always want to release distribution packages.

I think you are coupling (virtually) different things related with the SDLC; source code management, packaging and distribution.

If the source code is under the umbrella of one repository or many should be irrelevant for its packaging and distribution.

Regardless the number of repositories and the version strategy involved, It should be possible for you to set a pipeline so that

• Pull the source code from 1/N repositories and from specific branches.
• Build the root project (non-recursive)
• Build all the modules or just a pre-selected one.
• Test the module/s
• Package the candidate artifact to be distributed, with the required modules/versions.
• Test the package (as a whole)
• Push one or all the binaries to the artifact repository.

Repeat #4 as many times as versions you need to prove compatibility with. It might involve repeating #1,#2 and #3 with different branches or download the existing binaries from the artifact repository.

Repeat #5 for every package in #4.

This should be possible regardless the version strategy because versions are tracked by the SCM (branches, tags, whatever) or by the artifact repository.

Under these circumstances - what is the meaning of the version number of the maven root project?

Only the one you need to provide with.

If the root project is mean to be integrable, keep the Semantic Version because is useful for consumers. You have to decide what changes on the modules cause the root project's version to change and how. That's up to you, we can't tell given the little context we have.

If not or if it's causing confusion, then change it.

Think in Android. Android is distributed following a different version strategy than the components or services It comprises.

I run Android A but the GBoard is x.y.z. There could be several patches but it's still A. There have been a couple of releases of GBoard since I installed Android A. I have installed both versions but my Android version remains the same.

Internally, Google probably follows a second strategy to track the different patched versions of Android A. Which one, I don't know. Probably one involving build dates and numbers.

What version should the distribution package have?

I don't think you are asking to the right audience.

I feel like a date-based approach might be better suited here. Make a distribution release every 6 months or so and call it 2020_06. If an important bugfix required the update of a component in between, a version like 2020_06.2 might work as well.

This answers your previous question. Note that you set the semantics according to one prupose, tracking versions and updates on the time. Yours is explaining to me that

• There could be several versions along the year.
• There could be updates of the current version

What it doesn't explain is

• Differences between versions
• Differences between versions and updates
• What to expect from each

If that's what you want me to know, then seems fine.

What I want to do is keep offering releases for the individual modules, because it makes updating much easier. (Bugfix release? just exchange the jar file). But I always want to release distribution packages.

I think you are coupling (virtually) different things related with the SDLC; source code management, packaging and distribution.

If the source code is under the umbrella of one repository or many is irrelevant for the packaging and its distribution. Also is the versioning strategy.

Regardless the number of repositories and the version strategy involved, It should be possible for you to set a pipeline that:

• Pull the source code from 1/N repositories and from specific branches.
• Build the root project (non-recursive)
• Build all the modules or just one (pre-selected).
• Test the module
• Package the candidate artifact for distribution with the required modules/versions.
• Test the package (as a whole)
• Publish one or all the binaries in the artifact repository. Say we only publish the new version of the module we are releasing.

Repeat #4 as many times as versions you need to prove compatibility with. It might involve repeating #1,#2 and #3 with different branches. Or download the existing binaries from the artifact repository.

Step 5 is repeated for every package in #4.

This should be possible even without semantic version because versions are tracked by the SCM (branches, tags, whatever) or by the artifact repository.

Under these circumstances - what is the meaning of the version number of the maven root project?

Only the one you want to provide with. If the root project is mean to be integrable, keep the Semantic Version because is useful for consumers. If not, if it's causing confusion then change it.

Think in Android. Android is distributed following a different version strategy than the modules or services It comprises.

I run Android A but the GBoard is x.y.z. There could be several patches but it's still A. There have been a couple of releases of GBoard since I installed Android A. I have installed both versions but my Android version remains the same.

Internally, Google probably follows a second strategy to track the different patched versions of Android A. Which one I don't know. Probably one involving build dates and numbers.

What version should the distribution package have?

I don't think you are asking to the right audience.

I feel like a date-based approach might be better suited here. Make a distribution release every 6 months or so and call it 2020_06. If an important bugfix required the update of a component in between, a version like 2020_06.2 might work as well.

This answers your previous question. Note that you set the semantics according to one prupose, tracking versions and updates on the time. From it I understand that

• There will be a different version the next year
• There could be up to 1 version per month.
• There could be updates this month

If that's whate you need to communicate, then go ahead.

What I want to do is keep offering releases for the individual modules, because it makes updating much easier. (Bugfix release? just exchange the jar file). But I always want to release distribution packages.

I think you are coupling (virtually) different things related with the SDLC; source code management, packaging and distribution.

If the source code is under the umbrella of one repository or many should be irrelevant for its packaging and distribution.

Regardless the number of repositories and the version strategy involved, It should be possible for you to set a pipeline so that

• Pull the source code from 1/N repositories and from specific branches.
• Build the root project (non-recursive)
• Build all the modules or just a pre-selected one.
• Test the module/s
• Package the candidate artifact to be distributed, with the required modules/versions.
• Test the package (as a whole)
• Push one or all the binaries to the artifact repository.

Repeat #4 as many times as versions you need to prove compatibility with. It might involve repeating #1,#2 and #3 with different branches or download the existing binaries from the artifact repository.

Repeat #5 for every package in #4.

This should be possible regardless the version strategy because versions are tracked by the SCM (branches, tags, whatever) or by the artifact repository.

Under these circumstances - what is the meaning of the version number of the maven root project?

Only the one you need to provide with. 

If the root project is mean to be integrable, keep the Semantic Version because is useful for consumers. You have to decide what changes on the modules cause the root project's version to change and how. That's up to you, we can't tell given the little context we have.

If not or if it's causing confusion, then change it.

Think in Android. Android is distributed following a different version strategy than the components or services It comprises.

I run Android A but the GBoard is x.y.z. There could be several patches but it's still A. There have been a couple of releases of GBoard since I installed Android A. I have installed both versions but my Android version remains the same.

Internally, Google probably follows a second strategy to track the different patched versions of Android A. Which one, I don't know. Probably one involving build dates and numbers.

What version should the distribution package have?

I don't think you are asking to the right audience.

I feel like a date-based approach might be better suited here. Make a distribution release every 6 months or so and call it 2020_06. If an important bugfix required the update of a component in between, a version like 2020_06.2 might work as well.

This answers your previous question. Note that you set the semantics according to one prupose, tracking versions and updates on the time. You sret basically explaining that

• There will be a different version the next year
• There could be up to 1 revision per month.
• There could be one or more updates this month

If that's what you want me to know, then seems fine.