On Sun, Aug 4, 2019 at 9:05 AM Neil C Smith <[email protected]> wrote:
> On Sun, 4 Aug 2019, 07:06 Jan Lahoda, <[email protected]> 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? > Because for non-release builds, it would be hard/impossible to find what sources were used to build the given module - it would even be misleading. And while that would typically be the "dev community", if the IDE log and/or About/Help are not identifying the sources, we will need to put that information manually into every bugreport. > > 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. > Right, I noticed that only after I sent the e-mail. Looking at what we've generated into netbeans/nb/build_info for the release build: NetBeans dev build ------------------ Number: netbeans-release-428-on-20190716 Date: 16 Jul 2019 Branding: Branch: trunk Tag: Hg ID: unknown-revn My hope is that, when changing the manifest attributes (and/or making the build reproducible), we could improve this information to actually allow to identify the original sources used to produce the binary. Jan > 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 > > > >
