EMF artifacts are deployed with same version/filename but different content/checksums

[sratz]

There seems to be something wrong with the version or qualifier updates:

Compare:

https://repo1.maven.org/maven2/org/eclipse/emf/org.eclipse.emf.ecore/2.42.0/org.eclipse.emf.ecore-2.42.0.jar
Bundle-Version: 2.42.0.v20251210-1145
369a89616ca1c1d051cd4c04a1921d5fbbdce19f98e55093327078d1152bc6e6

https://download.eclipse.org/releases/2026-03/202603111000/plugins/org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar
Bundle-Version: 2.42.0.v20251210-1145
369a89616ca1c1d051cd4c04a1921d5fbbdce19f98e55093327078d1152bc6e6

https://download.eclipse.org/releases/2026-06/202606101000/plugins/org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar
Bundle-Version: 2.42.0.v20251210-1145
ee0b1f003d1ad644e2b938ce291578799932bce2d102dae2fed8a3699c2c89d2

Extracting and diffing the 2026-03/Maven and 2026-06 jar content yields:

diff '--color=auto' -u -r org.eclipse.emf.ecore-2.42.0_2026_03/about.mappings org.eclipse.emf.ecore-2.42.0_2026_06/about.mappings
--- org.eclipse.emf.ecore-2.42.0_2026_03/about.mappings	2026-02-23 05:43:10.000000000 +0100
+++ org.eclipse.emf.ecore-2.42.0_2026_06/about.mappings	2026-05-23 15:23:06.000000000 +0200
@@ -1,5 +1,5 @@
 # about.mappings
 # contains fill-ins for about.properties
 
-0=202602230641
-1=47ea84d7fe507884c36b32f878c735e0a5ff66bb
+0=202605231520
+1=755e2c27c1444945b7e0c2dd1c0a692e6389f42c
Binary files org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/ECLIPSE_.RSA and org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/ECLIPSE_.RSA differ
diff '--color=auto' -u -r org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/ECLIPSE_.SF org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/ECLIPSE_.SF
--- org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/ECLIPSE_.SF	2026-02-23 05:43:16.000000000 +0100
+++ org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/ECLIPSE_.SF	2026-05-23 15:23:12.000000000 +0200
@@ -1,8 +1,8 @@
 Signature-Version: 1.0
 Created-By: 11.0.24 (Eclipse Adoptium)
-SHA-256-Digest-Manifest: NOIpctNFBCb2D5IO2CtLt7LXo10d/r5yYbrSX2G2+Ws=
-SHA-256-Digest-Manifest-Main-Attributes: Mfc25ZONCHDxg9VNoW4wRnT/+p4LqBq
- cwIekpL5qoOc=
+SHA-256-Digest-Manifest: cGBO3pARNC2IAXIQ63wOe9tdJ7VBN8fg8p8jg2hP3q4=
+SHA-256-Digest-Manifest-Main-Attributes: sITiN0/m46oi78S9wB5o4R9EeUBU4Tp
+ S4aXYmRRuxsE=
 
 Name: org/eclipse/emf/ecore/impl/EPackageRegistryImpl$Delegator.class
 SHA-256-Digest: qf2O8iEEB8jA/7YX3EbHJisB16LnJhP/hHAkxHrJGiU=
@@ -202,7 +202,7 @@
 SHA-256-Digest: 3LYKx7ERSjqcL7rPxzFxer4AcWbqQTVXl44p/KhsxqM=
 
 Name: about.mappings
-SHA-256-Digest: Yb9O/TETIoowVhIdelL3yiZFd3+Da04Bh6Rib69vZGk=
+SHA-256-Digest: nE++0freTpY6Vxbt312tSWrsg88IYknnJujCdlNS00Y=
 
 Name: org/eclipse/emf/ecore/resource/ContentHandler$Registry.class
 SHA-256-Digest: V6NsmCfLoNAo8W9hY7aysa1ZNMm7FKzNFMFwvwtSjjQ=
@@ -1672,7 +1672,7 @@
 SHA-256-Digest: U6wLgn7BRRk1RdsTql1fOEs8SkmDLePGJk44Bc7fM/4=
 
 Name: META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml
-SHA-256-Digest: PJmBdXZOykRZ3R/6rmWCs50GzTgKu4KIdaZVnYpgUx8=
+SHA-256-Digest: 6Ed6jfWJbTJGGNWAcX7RhogkhI2Wyz//diWZMjvRt+E=
 
 Name: org/eclipse/emf/ecore/impl/DynamicEObjectImpl$BasicEMapEntry.class
 SHA-256-Digest: YTEg81K7aRh+V3XaK0HTjAO41cjC0YiNJDyZMzsOWNA=
diff '--color=auto' -u -r org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/MANIFEST.MF org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/MANIFEST.MF
--- org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/MANIFEST.MF	2026-02-23 05:43:16.000000000 +0100
+++ org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/MANIFEST.MF	2026-05-23 15:23:12.000000000 +0200
@@ -1,5 +1,5 @@
 Manifest-Version: 1.0
-Created-By: Maven Archiver 3.6.5
+Created-By: Maven Archiver 3.6.6
 Build-Jdk-Spec: 21
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
@@ -46,8 +46,8 @@
 Bundle-ActivationPolicy: lazy
 Automatic-Module-Name: org.eclipse.emf.ecore
 Eclipse-SourceReferences: scm:git:https://github.com/eclipse-emf/org.ecl
- ipse.emf.git;path="plugins/org.eclipse.emf.ecore";commitId=47ea84d7fe50
- 7884c36b32f878c735e0a5ff66bb
+ ipse.emf.git;path="plugins/org.eclipse.emf.ecore";commitId=755e2c27c144
+ 4945b7e0c2dd1c0a692e6389f42c
 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
 
 Name: org/eclipse/emf/ecore/impl/EPackageRegistryImpl$Delegator.class
@@ -248,7 +248,7 @@
 SHA-256-Digest: NxvIyUy41FeitOzwqAdjPE+ArL3hF9nTSsUpXp+Jziw=
 
 Name: about.mappings
-SHA-256-Digest: Ew1FJ+fyHCQHj7kGCbPo+ZzogxaeVYTg6X/thX9wvI4=
+SHA-256-Digest: 2BRaAgqeP4jkMlnx/S0ufzHX0kNfTIfaNUgUidMGm8s=
 
 Name: org/eclipse/emf/ecore/resource/ContentHandler$Registry.class
 SHA-256-Digest: cHW5zEMY9lv92WsElPLZPKGXytvLD2jP4QHmYuQGkUA=
@@ -1718,7 +1718,7 @@
 SHA-256-Digest: fzVVYzujzcF0twbk8Iuu8zsrxzWinkIbZKLuw4jFFk8=
 
 Name: META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml
-SHA-256-Digest: Cx/CR6+8IIFMpZ3AXSzR4MzDHdFJ49XY9a3POhul6FI=
+SHA-256-Digest: AIMAf0Z39mgblfxf3NvxWr9kCLImmc+redPQg1MDBwo=
 
 Name: org/eclipse/emf/ecore/impl/DynamicEObjectImpl$BasicEMapEntry.class
 SHA-256-Digest: Hr54W38n62IeX80uWO+0JIgM5zTnBE2DvUOwFX0EjGg=
diff '--color=auto' -u -r org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml
--- org.eclipse.emf.ecore-2.42.0_2026_03/META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml	2026-02-23 05:43:14.000000000 +0100
+++ org.eclipse.emf.ecore-2.42.0_2026_06/META-INF/maven/org.eclipse.emf/org.eclipse.emf.ecore/pom.xml	2026-05-23 15:23:08.000000000 +0200
@@ -22,7 +22,7 @@
     <dependency>
       <groupId>org.apache.felix</groupId>
       <artifactId>org.apache.felix.scr</artifactId>
-      <version>2.2.14</version>
+      <version>2.2.18</version>
       <scope>compile</scope>
     </dependency>
     <dependency>

Looks like some version bump was missing?

[sratz]

This leads to some "interesting" problem:

• Run a build that depends on org.eclipse.emf.ecore and exposes EMF interfaces as API with Tycho tycho-apitools-plugin:verify
• During compilation:
  Downloaded from p2: https://download.eclipse.org/releases/2026-06/202606101000/plugins/org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar (1 MB at 17 MB/s)
  to
  ~\.m2\p2\osgi\bundle\org.eclipse.emf.ecore\2.42.0.v20251210-1145\org.eclipse.emf.ecore-2.42.0.v20251210-1145.jar
• During compilation, the jar file is mapped to a jdk.nio.zipfs.ZipFileSystem.
• org.eclipse.jdt.internal.compiler.util.JRTUtil.getJarFileSystem(Path) keeps all those ZipFileSystem open for re-use.
• During API tooling execution the file
  ~\.m2\p2\osgi\bundle\org.eclipse.emf.ecore\2.42.0.v20251210-1145\org.eclipse.emf.ecore-2.42.0.v20251210-1145.jar
  is somehow replaced with the Maven artifact (lot's of seemingly redundant disk writes going on there)
• The ZipFileSystem still uses the file offsets from the first one
• API tooling cannot extract .class file content because all the zip file offsets are wrong.

The build eventually fails with

...
java.lang.NullPointerException: Cannot invoke "org.eclipse.pde.api.tools.internal.provisional.model.IApiType.getHandle()" because "typeDescriptor" is null
    at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator$3.visit (ApiComparator.java:784)
    at org.eclipse.pde.api.tools.internal.model.ArchiveApiTypeContainer.accept (ArchiveApiTypeContainer.java:166)
    at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.internalCompare (ApiComparator.java:777)
    at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare (ApiComparator.java:284)
    at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare (ApiComparator.java:307)
    at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.checkCompatibility (BaseApiAnalyzer.java:1454)
    at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.analyzeComponent (BaseApiAnalyzer.java:273)
    at org.eclipse.tycho.apitools.ApiAnalysis.performAPIAnalysis (ApiAnalysis.java:253)
    at org.eclipse.tycho.apitools.ApiAnalysis$2.runInWorkspace (ApiAnalysis.java:222)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run (InternalWorkspaceJob.java:43)
    at org.eclipse.core.internal.jobs.Worker.run (Worker.java:63)

[merks]

I've never done baseline replace with EMF, so builds will produce bundles with mapping details and signatures based on the current build. As a result, mapping things to Maven Central is really not a good plan because there is no guarantee that this is a good thing. It seems there is some new caching behavior in Tycho because it (EMF's build) has always been this way...

[sratz]

But shouldn't any P2 artifact always be unique? If the content changes the version must too.

[merks]

As I said, it's been exactly this way for a very long time. In fact I expect every build to produce a slightly different artifact because it's designed to do exactly that:

I guess long ago someone thought such traceability would be a good thing...

I expect what's changed is some caching behavior in Tycho. It seems to want to download things form Maven Central, even though I never want that; in other builds it causes warnings that I don't know how to eliminate.

[sratz]

Interesting, I always thought that was pretty much a "golden rule" of OSGi: Every artifact is unique. If you change the content / signing certificate / it has to get a new version.

I can think of many more things that would go wrong if the "same" (name/version) artifact is somehow reachable via different coordinates and different content/checksums

• Packaging in products would not pick the artifact deterministically.
• Caching in CDNs might fail
• ...

I traced this build failure back to where the artifact is written. Maven coordinates are not involved here. It's actually just what happens when the API tooling resolves the baseline. Our baseline we compare against contains the "old" (2026-03) version of EMF, the main branch builds against 2026-06. So the following happens:

• Compilation step starts. File is written with 2026-06 version
• API tooling starts and resolves baseline. File is written again with 2026-03 version

 at org.eclipse.tycho.p2.repository.ArtifactRepositoryBaseImpl$AddingArtifactSink.beginWrite (ArtifactRepositoryBaseImpl.java:444)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider.getArtifactFromOneMirror (RepositoryArtifactProvider.java:243)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror (RepositoryArtifactProvider.java:223)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider$1.perform (RepositoryArtifactProvider.java:198)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact (SimpleArtifactRepository.java:870)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts (SimpleArtifactRepository.java:959)
    at org.eclipse.tycho.p2.repository.LazyArtifactRepository.getArtifacts (LazyArtifactRepository.java:102)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository (RepositoryArtifactProvider.java:210)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository (RepositoryArtifactProvider.java:177)
    at org.eclipse.tycho.p2.repository.RepositoryArtifactProvider.getArtifactFromAnySource (RepositoryArtifactProvider.java:163)
    at org.eclipse.tycho.p2.repository.CompositeArtifactProviderBaseImpl.getArtifact (CompositeArtifactProviderBaseImpl.java:55)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.downloadCanonicalArtifact (MirroringArtifactProvider.java:347)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact (MirroringArtifactProvider.java:340)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.downloadArtifact (MirroringArtifactProvider.java:325)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.makeOneFormatLocallyAvailable (MirroringArtifactProvider.java:264)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.makeLocallyAvailable (MirroringArtifactProvider.java:206)
    at org.eclipse.tycho.p2.repository.MirroringArtifactProvider.getArtifactFile (MirroringArtifactProvider.java:138)
    at org.eclipse.tycho.p2.repository.CompositeArtifactProvider.getArtifactFile (CompositeArtifactProvider.java:89)
    at org.eclipse.tycho.p2resolver.TargetPlatformBaseImpl.getLocalArtifactFile (TargetPlatformBaseImpl.java:169)
    at org.eclipse.tycho.core.resolver.DefaultP2ResolutionResult.lambda$addArtifact$2 (DefaultP2ResolutionResult.java:90)
    at org.eclipse.tycho.core.resolver.DefaultP2ResolutionResultEntry.getLocation (DefaultP2ResolutionResultEntry.java:73)
    at org.eclipse.tycho.osgi.framework.EclipseApplicationFactory.getApiBaselineBundles (EclipseApplicationFactory.java:128)
    at org.eclipse.tycho.apitools.ApiApplicationResolver.getApiBaselineBundles (ApiApplicationResolver.java:57)
    at org.eclipse.tycho.apitools.ApiAnalysisMojo.getBaselineBundles (ApiAnalysisMojo.java:380)
    at org.eclipse.tycho.apitools.ApiAnalysisMojo.execute (ApiAnalysisMojo.java:201)

[merks]

Given how many things could go wrong one has to wonder why has it gone on so long without anything actually going wrong. In the end, it doesn’t much matter which one is picked, but changing it once picked is clearly a bad strategy and that strategy must be a new one.

[sratz]

Given how many things could go wrong one has to wonder why has it gone on so long without anything actually going wrong

Yeah no idea, we probably just got lucky?

In the end, it doesn’t much matter which one is picked, but changing it once picked is clearly a bad strategy and that strategy must be a new one.

Both steps (compilation and api tooling) go via org.eclipse.jdt.internal.compiler.util.JRTUtil.getJarFileSystem(Path) which caches the file systems and never closes them.

But apparently in the JDK's ZipFileSystem there also is

• no write lock on the jar file
• no mechanism to detect that the jar file has changed on disk

and it's possible to exchange the jar file on disk with the ZipFileSystem still "open" without anyone noticing.

[merks]

It’s all water under the bridge at this point. Significant restructuring of the build will be required, including getting rid of build timestamps from the about. 💶

[merks]

I experimented and it's not all that much work to change the build.

        <plugin>
          <groupId>org.eclipse.tycho</groupId>
          <artifactId>tycho-p2-plugin</artifactId>
          <version>${tycho-version}</version>
          <configuration>
            <baselineMode>fail</baselineMode>
            <baselineReplace>all</baselineReplace>
            <baselineRepositories>
              <repository>
                <url>https://download.eclipse.org/modeling/emf/emf/builds/release/latest</url>
              </repository>
              <repository>
                <url>https://download.eclipse.org/modeling/emf/emf/builds/nightly/latest</url>
              </repository>
            </baselineRepositories>
            <ignoredPatterns>
              <pattern>META-INF/ECLIPSE_.RSA</pattern>
              <pattern>META-INF/ECLIPSE_.SF</pattern>
              <pattern>about.mappings</pattern>
            </ignoredPatterns>
          </configuration>
        </plugin>

So I could use the

• https://download.eclipse.org/modeling/emf/emf/builds/release/latest
• https://download.eclipse.org/modeling/emf/emf/builds/nightly/latest

But even these two will have inconsistencies and I'm not sure which of the two would be picked.

I'm not sure if I understand 100% correctly, but if I use only this

• https://download.eclipse.org/modeling/emf/emf/builds/release/latest

Then each night build artifact will replace with a release artifact, but a newly-produced artifact (because of some actual change) would product a newly signed bundle with each build if the nightly build repository this isn't also part of the baseline

• https://download.eclipse.org/modeling/emf/emf/builds/nightly/latest

That would not be 100% ideal either.

Given past inconsistencies, I'm not sure the best way to ensure 100% consistency going forward from now. Force a qualifier update on every artifact? Even then, new Maven versions are published only if at least the micro version changes, so all the things published to Maven should be version bumped to ensure a newly signed artifact consistent with the final release artifact is published at the end of the release, I guess...

Given I don't know exactly what is going wrong with your build, I'm not 100% sure how to ensure it never happens again. So it seems forcing qualifier changes for everything and forcing actual version increments for all things publish to Maven Central would be safest.

@sratz

Do you have any thoughts or opinions on the above proposal and assessment?

[sratz]

Thanks, Ed, for looking into this further!

This sounds like a valid solution.

I'm not exactly sure I understand the not-100% scenario:
My assumptions would be the following:

• Comparison against baseline modulo signing -> if nothing changed, the previous build artifact is included
• If there is a real change a qualifier bump is a must -> new artifact with new qualifier is deployed to /nightly and eventually to /release. if the qualifier is not bumped, build should fail.

That way, how can there still be non-unique artifacts across /nightly and /release? Is it just for the initial time we apply that baseline logic until we transition into a more consistent state? Maybe then we could just do an artificial micro bump once?

Regarding what's actually happening. I debugged this further:

1. Setup: Target platform -> 2026-06. API tooling baseline -> 2026-03. Both ship org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar with identical filename+version but different SHA-256 / content.
2. Target platform resolution: Tycho downloads the 2026-06 jar to the shared p2 cache: ~/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore/2.42.0.v20251210-1145/...jar.
3. ZipFileSystem opened: ECJ opens a ZipFileSystem on the cached jar to probe for META-INF/versions/ (org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar). Probe returns negative, but the file system stays open.
4. API tooling baseline resolution: API tooling resolves against 2026-03, sees a checksum mismatch on the same path, re-downloads the 2026-03 jar, overwrites the file in place.
5. Backing bytes diverge from open FS state: The open ZipFileSystem from step 2 still holds file offsets from the 2026-06 jar. But on disk there are now 2026-03 bytes.
6. API tooling reads actual class entries: Reads go through the open ZipFileSystem (not a fresh open). Entries resolve to wrong offsets -> ZipException / corrupted reads -> build fails

The re-download in step 4 can be seen in the log when running with mvn -C (strict checksums):

...
[WARNING] sha-256 checksum for /home/user/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore/2.42.0.v20251210-1145/org.eclipse.emf.ecore-2.42.0.v20251210-1145.jar does not match, attempting to download file again...
[INFO] Downloading from p2: https://download.eclipse.org/releases/2026-03/202603111000/plugins/org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar
[INFO] Downloaded from p2: https://download.eclipse.org/releases/2026-03/202603111000/plugins/org.eclipse.emf.ecore_2.42.0.v20251210-1145.jar (1 MB at 39 MB/s)
...

So we have several other players in the game:

• ECJ (org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar) opening ZipFileSystem but not closing them
• Tycho API Tooling using the same target resolution infrastructure for baseline resolution and re-using the same disk location

Both are OK if the assumption is that jar files are supposed to be unique per version.

By the way: IF emf.ecore would be a multiple release jar and you had a setup like

pom.xml
\-module1: target 2026-03, compile against EMF with Java 17
\-module2: target 2026-06, compile against EMF with Java 21

the compilation would fail already.

By the way: I mitigated this issue in our build now by hooking (with a maven core build extension) using ByteBuddy/ASM and by closing all existing/open ZipFileSystems when jar files are written in org.eclipse.tycho.p2.repository.ArtifactRepositoryBaseImpl$AddingArtifactSink. This works.

Adding @laeubi here as well: Do you think that could be something we could implement in Tycho as a mitigation?

[laeubi]

Tycho uses P2 under the hood and for P2 the same version+id is considered "the same thing" I don't think that there is any way to mitigate this as this is deeply inside everywhere (including cache file path).

[sratz]

eclipse-tycho/tycho#6128 mitigates the issue in our build (at least when running a non-parallel build).

[laeubi]

eclipse-tycho/tycho#6128 mitigates the issue in our build (at least when running a non-parallel build).

I don't think this is really a valid solution. This will produce heavy I/O and likley issues with parallel builds just to fix a case that actually should never happen.

[sratz]

I don't think this is really a valid solution. This will produce heavy I/O and likley issues with parallel builds just to fix a case that actually should never happen.

The I/O overhead of closing the zip file mmap should be minimal in comparison to writing the actual full .jar file which is just happening in this method.

But yeah, I agree, this is not really a solid solution.

[merks]

In the long term, I think it makes sense to have only the nightly as the baseline:

https://download.eclipse.org/modeling/emf/emf/builds/nightly/latest

Assuming a nightly build is always done as the first thing after any committed changes, anything new will show up there first. Any subsequent build will copy from that baseline, except for things that are actually changed relative to that baseline. That should be sufficient for proper behavior.

To ensure that everything get onto a good track, I should ensure that every bundle (and feature) gets a new version for this release cycle. I think it would probably be good to do this when there is a new signing certificate which I think should arrive mid July:

So I will probably defer taking action until M2...