On Sun, 4 Aug 2019, 07:06 Jan Lahoda, <lah...@gmail.com> wrote: > So, for reproducible builds, > we need to solve the OpenIDE-Module-Build-Version attribute. >
True. This is definitely only about the auto-generated attributes. It's not just about reproducible builds though, which we'd still have some way to get to. I don't like that we had to pull the first NB11.1 Maven vote because of this attribute. > For implementation version, using the literal spec. version would be a nice > trick, but it is difficult to to me to accept that for the build version. > Can I ask why? How is it being used outside of specifying a particular release? So, using git hash feels like a reasonable solution (and we already do that > for the build version, only prepend the current date!). Actually, we're not on the release builds - they have Jenkins build info instead. For Apache > releases, we could print the git hash into a file in the source distro, and > read it from that file. Having the source hash in the source distro might > be a good idea anyway. > Yes, this was discussed in the PR linked earlier, along with including public-facing version info via file. We need to ensure that zip build and git build give the same thing. I share some of Emi's concerns with this approach, although it could solve the immediate issue. Best wishes, Neil >
