Re: Aligning implementation and specification versions?
Create a PR to make the API public! -jt Odesláno z iPadu > 3. 10. 2019 v 3:31, Tim Boudreau : > > +1 - I recently found that to have a preview for a formatter requires a > friend dependency, which is ridiculous given that the API has not changed > in many years. > > -Tim > >> On Wed, Sep 25, 2019 at 7:29 AM Neil C Smith wrote: >> >>> On Sun, 25 Aug 2019 at 19:06, Jesse Glick wrote: >>> A long time ago I wrote up >>> http://wiki.netbeans.org/NbmPackageStability to discuss problems with >>> the versioning scheme in NB and propose a different system. At this >>> point I would say that the proposed change is unnecessarily complex, >>> and that better development practices would avoid most problems: >> >> Missed this reply at the time - just found it looking for this thread. >> I like the proposal you wrote, and argued for considering it when >> there was a vote a while back on what to do with friend dependencies. >> Not that that vote really led to much conclusive. I personally >> probably agree with your assessment on the complexity, and the >> suggestions seem good - in particular >> >>> · Use simple specification version dependencies, and mark all packages >>> public which you would expect any other modules to refer to. >> >> ... yes, please let's just do this for NB 11.3 in preparation for next >> LTS! The active PRs to add friend access for third-party plugins are >> just wrong on so many levels. Let's keep friends only for the >> minority of legitimate cases where a module has optional extensions >> that need to be separate. >> >> Best wishes, >> >> Neil >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> -- > http://timboudreau.com - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
+1 - I recently found that to have a preview for a formatter requires a friend dependency, which is ridiculous given that the API has not changed in many years. -Tim On Wed, Sep 25, 2019 at 7:29 AM Neil C Smith wrote: > On Sun, 25 Aug 2019 at 19:06, Jesse Glick wrote: > > A long time ago I wrote up > > http://wiki.netbeans.org/NbmPackageStability to discuss problems with > > the versioning scheme in NB and propose a different system. At this > > point I would say that the proposed change is unnecessarily complex, > > and that better development practices would avoid most problems: > > Missed this reply at the time - just found it looking for this thread. > I like the proposal you wrote, and argued for considering it when > there was a vote a while back on what to do with friend dependencies. > Not that that vote really led to much conclusive. I personally > probably agree with your assessment on the complexity, and the > suggestions seem good - in particular > > > · Use simple specification version dependencies, and mark all packages > > public which you would expect any other modules to refer to. > > ... yes, please let's just do this for NB 11.3 in preparation for next > LTS! The active PRs to add friend access for third-party plugins are > just wrong on so many levels. Let's keep friends only for the > minority of legitimate cases where a module has optional extensions > that need to be separate. > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- http://timboudreau.com
Re: Aligning implementation and specification versions?
On Sun, 25 Aug 2019 at 19:06, Jesse Glick wrote: > A long time ago I wrote up > http://wiki.netbeans.org/NbmPackageStability to discuss problems with > the versioning scheme in NB and propose a different system. At this > point I would say that the proposed change is unnecessarily complex, > and that better development practices would avoid most problems: Missed this reply at the time - just found it looking for this thread. I like the proposal you wrote, and argued for considering it when there was a vote a while back on what to do with friend dependencies. Not that that vote really led to much conclusive. I personally probably agree with your assessment on the complexity, and the suggestions seem good - in particular > · Use simple specification version dependencies, and mark all packages > public which you would expect any other modules to refer to. ... yes, please let's just do this for NB 11.3 in preparation for next LTS! The active PRs to add friend access for third-party plugins are just wrong on so many levels. Let's keep friends only for the minority of legitimate cases where a module has optional extensions that need to be separate. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
On Fri, Aug 2, 2019 at 4:52 AM Neil C Smith wrote: > eliminate the annoyance that is friend > dependencies (or at least provide ways to externally override) https://github.com/jglick/yenta lets you override this. YMMV A long time ago I wrote up http://wiki.netbeans.org/NbmPackageStability to discuss problems with the versioning scheme in NB and propose a different system. At this point I would say that the proposed change is unnecessarily complex, and that better development practices would avoid most problems: · Use simple specification version dependencies, and mark all packages public which you would expect any other modules to refer to. · If an API is intended to be used only under certain circumstances, document that. · If you suspect an API might be wrong and might be broken in the future, document that in boldface. · If you have no choice but to make a breaking change, communicate it properly. Look proactively for clients which might be broken, and offer fixes for them in advance. · Treat version numbers as an opaque ordering—just increasing numbers. Do not pretend that different components of a version number mean anything about compatibility. Without data, you do not know this. · Run integration tests aggressively. · Use Dependabot to keep dependencies up to date, so incompatibilities do not catch you by surprise. · If as a client you do find an incompatibility, communicate that to the developer of the API. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
Sounds great. Fork away! :-) -Tim On Tue, Aug 6, 2019 at 4:51 AM Dmitry Avtonomov wrote: > Looks like `--deep` mode needs to be made default and shallow mode renamed > to something like `--sigs-only` > > On Sun, Aug 4, 2019 at 2:27 AM Tim Boudreau wrote: > > > Well, since I mentioned I'd poked at writing a Java code signature > hashing > > tool, I figured why not finish it, so, if anyone's interested, here you > > go. The readme explains what it does: > > > > https://github.com/timboudreau/signature-hash > > > > Wrote a few tests that pass (same hash with differently formatted code, > or > > code with or without a private method), and tried it on a few projects > > making changes. Jan Lahoda, you're probably one of the few people on the > > planet that could look at this and see if there's anything glaringly > wrong > > with it :-) > > > > It builds to a command-line executable JAR, but could easily be made into > > an Ant or Maven plugin or whatever. Hashing the signatures of things > that > > actually get *called* seems like it would be far superior to git hashes, > > where inconsequential changes would result in a false-incompatibility > > reading. > > > > -Tim > > > -- http://timboudreau.com
Re: Aligning implementation and specification versions?
Looks like `--deep` mode needs to be made default and shallow mode renamed to something like `--sigs-only` On Sun, Aug 4, 2019 at 2:27 AM Tim Boudreau wrote: > Well, since I mentioned I'd poked at writing a Java code signature hashing > tool, I figured why not finish it, so, if anyone's interested, here you > go. The readme explains what it does: > > https://github.com/timboudreau/signature-hash > > Wrote a few tests that pass (same hash with differently formatted code, or > code with or without a private method), and tried it on a few projects > making changes. Jan Lahoda, you're probably one of the few people on the > planet that could look at this and see if there's anything glaringly wrong > with it :-) > > It builds to a command-line executable JAR, but could easily be made into > an Ant or Maven plugin or whatever. Hashing the signatures of things that > actually get *called* seems like it would be far superior to git hashes, > where inconsequential changes would result in a false-incompatibility > reading. > > -Tim >
Re: Specification version is for features; Implementation version to workaround bugs was: Aligning implementation and specification versions?
On Mon, Aug 5, 2019 at 3:13 AM Jaroslav Tulach wrote: > Lively discussion. I can't pretend I read it all, but... But read the readme on the github site about "deep" mode, which addresses your objection to hashing only method signatures. I think I anticipated your objection. The problem that is worth solving here is the case where module A has an implementation dependency on module B which rarely changes, and a new release of A (as part of the IDE - this is the most common case) breaks module A, even though NO CODE HAS CHANGED in module B. That is a silly situation. Git commit IDs won't solve it. Build dates we already know can't solve it. What solves it perfectly is a hash only of those elements that the compiler turns into code. License header changes don't affect it. Renaming private variables doesn't affect it. Reformatting doesn't affect it. But alter the control flow in any way, and you get a different hash. I think the more interesting application of this (and the reason I started playing with this idea a few years ago) is it you keep hashes for every public method. You upgrade a library and wonder how much you should worry that something broke, and how much QA you should plan for. Wouldn't it be nicer if you could literally know what percentage of the code you actually touch has changed? Stick that together with eigenvector centrality (a measure of connector-ness - most connected through, not to) values for the things that changed, and you could compute a simple score for the risk of a library upgrade as it applies to YOUR code and the things it really calls. -Tim > > I'd like to remind you that: > - specification version is used to depend on features > - implementation version is used to depend on bug-to-bug compatibility > > E.g. use specification version to depend on properly versioned API. Use > implementation version to workaround bugs in behavior. > > From this point of view it makes sense make implementation version = git > hash. Checksum of available methods isn't really appropriate as bugs in > behavior happen in the method bodies, not in signatures. > > -jt > > > ne 4. 8. 2019 v 11:27 odesílatel Tim Boudreau > napsal: > > > Well, since I mentioned I'd poked at writing a Java code signature > hashing > > tool, I figured why not finish it, so, if anyone's interested, here you > > go. The readme explains what it does: > > > > https://github.com/timboudreau/signature-hash > > > > Wrote a few tests that pass (same hash with differently formatted code, > or > > code with or without a private method), and tried it on a few projects > > making changes. Jan Lahoda, you're probably one of the few people on the > > planet that could look at this and see if there's anything glaringly > wrong > > with it :-) > > > > It builds to a command-line executable JAR, but could easily be made into > > an Ant or Maven plugin or whatever. Hashing the signatures of things > that > > actually get *called* seems like it would be far superior to git hashes, > > where inconsequential changes would result in a false-incompatibility > > reading. > > > > -Tim > > > -- http://timboudreau.com
Re: Specification version is for features; Implementation version to workaround bugs was: Aligning implementation and specification versions?
On Mon, 5 Aug 2019 at 08:13, Jaroslav Tulach wrote: > Lively discussion. I can't pretend I read it all, but... :-) > I'd like to remind you that: > - specification version is used to depend on features > - implementation version is used to depend on bug-to-bug compatibility +1 Agreed! Neither proposal was intended to change the semantics of impl version - just make it work in the land of source releases. > From this point of view it makes sense make implementation version = git > hash. Checksum of available methods isn't really appropriate as bugs in > behavior happen in the method bodies, not in signatures. Yes! I still have some reservations about git hash due to the complexities it brings in for making it work with and without git info present, and some of the other things Tim brought up, but looks like the way forward. The desire to change semantics there and in the pulled Maven release thread do bring up the need to figure out why people are having to resort to impl. dependencies anywhere and what we should do to address that. Consistent impl. versions should really only be a concern for reproducible builds, but that's obviously not the only issue at present. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Specification version is for features; Implementation version to workaround bugs was: Aligning implementation and specification versions?
Lively discussion. I can't pretend I read it all, but... I'd like to remind you that: - specification version is used to depend on features - implementation version is used to depend on bug-to-bug compatibility E.g. use specification version to depend on properly versioned API. Use implementation version to workaround bugs in behavior. >From this point of view it makes sense make implementation version = git hash. Checksum of available methods isn't really appropriate as bugs in behavior happen in the method bodies, not in signatures. -jt ne 4. 8. 2019 v 11:27 odesílatel Tim Boudreau napsal: > Well, since I mentioned I'd poked at writing a Java code signature hashing > tool, I figured why not finish it, so, if anyone's interested, here you > go. The readme explains what it does: > > https://github.com/timboudreau/signature-hash > > Wrote a few tests that pass (same hash with differently formatted code, or > code with or without a private method), and tried it on a few projects > making changes. Jan Lahoda, you're probably one of the few people on the > planet that could look at this and see if there's anything glaringly wrong > with it :-) > > It builds to a command-line executable JAR, but could easily be made into > an Ant or Maven plugin or whatever. Hashing the signatures of things that > actually get *called* seems like it would be far superior to git hashes, > where inconsequential changes would result in a false-incompatibility > reading. > > -Tim >
Re: Aligning implementation and specification versions?
Well, since I mentioned I'd poked at writing a Java code signature hashing tool, I figured why not finish it, so, if anyone's interested, here you go. The readme explains what it does: https://github.com/timboudreau/signature-hash Wrote a few tests that pass (same hash with differently formatted code, or code with or without a private method), and tried it on a few projects making changes. Jan Lahoda, you're probably one of the few people on the planet that could look at this and see if there's anything glaringly wrong with it :-) It builds to a command-line executable JAR, but could easily be made into an Ant or Maven plugin or whatever. Hashing the signatures of things that actually get *called* seems like it would be far superior to git hashes, where inconsequential changes would result in a false-incompatibility reading. -Tim
Re: Aligning implementation and specification versions?
On Sun, 4 Aug 2019, 09:08 Jan Lahoda, wrote: > 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. > Ah, yes! Thinking about this too much from a technical module interaction point of view, rather than the human one. Did have to check this multiple times with recent beta reports, although other changes mean the beta versions should be marked in the version next time around. 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. > OK, sounds like getting git hash into the sources for module build version has to be what to aim at for NB 11.2 then. We could still consider whether it should be used for impl version later, but changing that wouldn't get around the need to have the git hash in the build (which is what I was hoping for). Thanks and best wishes, Neil >
Re: Aligning implementation and specification versions?
> (Frankly, recording the source hash in the source distro feels like a reasonable idea to me in any case - currently, if I see a source zip of NetBeans, the only clue I have about the contents is the filename; that feels very weak.) Good point. --emi On Sun, Aug 4, 2019 at 11:08 AM Jan Lahoda wrote: > > On Sun, Aug 4, 2019 at 9:05 AM Neil C Smith wrote: > > > On Sun, 4 Aug 2019, 07:06 Jan Lahoda, 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 > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
On Sun, Aug 4, 2019 at 9:05 AM Neil C Smith wrote: > On Sun, 4 Aug 2019, 07:06 Jan Lahoda, 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 > > > >
Re: Aligning implementation and specification versions?
On Sun, 4 Aug 2019, 07:06 Jan Lahoda, 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 >
Re: Aligning implementation and specification versions?
On Sun, Aug 4, 2019 at 8:37 AM Emilian Bold wrote: > > 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. > > But then a release ZIP won't just be just a checkout of a commit ID > but a generated ZIP file with other stuff in it. > But it already isn't just the checkout, right? We don't pack some modules into the distro, and we generate LICENSE and NOTICE based on what is in the source zip (ASF requirement is that LICENSE and NOTICE must contain only what is needed for the given zip, nothing more, nothing less). (Frankly, recording the source hash in the source distro feels like a reasonable idea to me in any case - currently, if I see a source zip of NetBeans, the only clue I have about the contents is the filename; that feels very weak.) > I would like that `git checkout 11.1 && ant build build-nbms > generate-uc-catalog` to be identical with the official release. > Not clear on how having the git hash recorded in the source distro is against this goal. Having the hash recorded would IMO actually help with that goal - regardless of whether the sources are checked out from the git repo, or unzipped from the zip, the hash that would be used would be the same. If we commit some ID to the repository, then two builds from two different hashes in git may get the same build version - that sounds to be against the very nature of the build version. Jan > --emi > > On Sun, Aug 4, 2019 at 9:06 AM Jan Lahoda wrote: > > > > Hi, > > > > Let me point out we have two manifest attributes: > > OpenIDE-Module-Build-Version and OpenIDE-Module-Implementation-Version. > The > > Build-Version is the generated one, based on the date and git hash. If a > > module specifies the impl. version, then both of these are generated, if > > the module does not specify the impl. version, then > > OpenIDE-Module-Implementation-Version is set to the build version, and > > OpenIDE-Module-Build-Version is not generated. So, for reproducible > builds, > > we need to solve the OpenIDE-Module-Build-Version 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. > > So, using git hash feels like a reasonable solution (and we already do > that > > for the build version, only prepend the current date!). 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. > > > > Jan > > > > On Sun, Aug 4, 2019 at 6:33 AM Emilian Bold > wrote: > > > > > Using git hash assumes your are building a cloned repository. By > > > definition this would not work on Apache releases which are just ZIP > > > files of a given revision. > > > > > > It might be simpler to just have a task that generates this stuff and > > > actually commit it when doing releases (or perhaps, have a bot > > > periodically commit it). > > > > > > --emi > > > > > > On Sat, Aug 3, 2019 at 10:06 PM Tim Boudreau > wrote: > > > > > > > > > It might solve that problem, it doesn't solve this problem! We're > > > trying to > > > > > get to a situation where different builds of the same source get > the > > > same > > > > > implementation versions. > > > > > > > > > > > > > For *that* problem, your best bet is to switch from build numbers to > > > using > > > > Git metadata. I do something similar for Maven libraries: > > > > > > > > https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin > > > > > > > > Here is the code that does the heavy lifting: > > > > > > > > https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java > > > > > > > > (in this case it is saving a properties file in META-INF, but easy > enough > > > > to write the same info to a manifest) > > > > > > > > The main issues are: > > > > - You have to assume a local git binary exists, and have some > heuristic > > > > for finding it (if you do this, please don't forget /opt/local/bin > for > > > > those of us that build NetBeans in Jenkins on SmartOS!) > > > > - You have to assume the local git binary may be old, and not > support > > > some > > > > of the newer date flags to git log > > > > - Git's idea of an ISO timestamp is not quite an ISO date as > > > > Instant.parse() understands it (but you only need the hash here, so > this > > > > probably doesn't matter) > > > > - If the repository is not clean (no modified sources since the last > > > > commit or pull), the best you can do is append "-dirty" to the > version > > > name > > > > and hope things work > > > > - It might be a good idea to blacklist from update servers any > module > > > > with "-dirty" in its implementation version, to ensure users can > actu
Re: Aligning implementation and specification versions?
> 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. But then a release ZIP won't just be just a checkout of a commit ID but a generated ZIP file with other stuff in it. I would like that `git checkout 11.1 && ant build build-nbms generate-uc-catalog` to be identical with the official release. --emi On Sun, Aug 4, 2019 at 9:06 AM Jan Lahoda wrote: > > Hi, > > Let me point out we have two manifest attributes: > OpenIDE-Module-Build-Version and OpenIDE-Module-Implementation-Version. The > Build-Version is the generated one, based on the date and git hash. If a > module specifies the impl. version, then both of these are generated, if > the module does not specify the impl. version, then > OpenIDE-Module-Implementation-Version is set to the build version, and > OpenIDE-Module-Build-Version is not generated. So, for reproducible builds, > we need to solve the OpenIDE-Module-Build-Version 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. > So, using git hash feels like a reasonable solution (and we already do that > for the build version, only prepend the current date!). 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. > > Jan > > On Sun, Aug 4, 2019 at 6:33 AM Emilian Bold wrote: > > > Using git hash assumes your are building a cloned repository. By > > definition this would not work on Apache releases which are just ZIP > > files of a given revision. > > > > It might be simpler to just have a task that generates this stuff and > > actually commit it when doing releases (or perhaps, have a bot > > periodically commit it). > > > > --emi > > > > On Sat, Aug 3, 2019 at 10:06 PM Tim Boudreau wrote: > > > > > > > It might solve that problem, it doesn't solve this problem! We're > > trying to > > > > get to a situation where different builds of the same source get the > > same > > > > implementation versions. > > > > > > > > > > For *that* problem, your best bet is to switch from build numbers to > > using > > > Git metadata. I do something similar for Maven libraries: > > > > > https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin > > > > > > Here is the code that does the heavy lifting: > > > > > https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java > > > > > > (in this case it is saving a properties file in META-INF, but easy enough > > > to write the same info to a manifest) > > > > > > The main issues are: > > > - You have to assume a local git binary exists, and have some heuristic > > > for finding it (if you do this, please don't forget /opt/local/bin for > > > those of us that build NetBeans in Jenkins on SmartOS!) > > > - You have to assume the local git binary may be old, and not support > > some > > > of the newer date flags to git log > > > - Git's idea of an ISO timestamp is not quite an ISO date as > > > Instant.parse() understands it (but you only need the hash here, so this > > > probably doesn't matter) > > > - If the repository is not clean (no modified sources since the last > > > commit or pull), the best you can do is append "-dirty" to the version > > name > > > and hope things work > > > - It might be a good idea to blacklist from update servers any module > > > with "-dirty" in its implementation version, to ensure users can actually > > > get the bits as compiled > > > > > > That gets you out of date-stamp land with something that is a more > > > dependable indicator of source-state - the git revision hash. > > > > > > I would strongly suggest *only* doing that for modules that *do not* > > > specify an explicit implementation version, but it would certainly be > > > better than a build number. That way, nothing that is already specifying > > > an implementation version breaks. Or if you want to be even more > > > conservative, leave the old build-number behavior on by default, and use > > > some switch to turn git hashes on for newly created modules, then > > > judiciously go through the sources and turn that switch on for existing > > > modules and make sure nothing breaks. > > > > > > I once played with writing a Java API signature hash generator that used > > > javac's API to mow through source code, and did some tricks with mapping > > > source elements and character sequences to prime numbers to create a hash > > > that only included public method signatures. Something like that would > > > probably be a more ideal solution (unless someone writes their API in, > > say, > > > Groovy - though if it processed .class files instead of sources, that > > would > > > solve
Re: Aligning implementation and specification versions?
Hi, Let me point out we have two manifest attributes: OpenIDE-Module-Build-Version and OpenIDE-Module-Implementation-Version. The Build-Version is the generated one, based on the date and git hash. If a module specifies the impl. version, then both of these are generated, if the module does not specify the impl. version, then OpenIDE-Module-Implementation-Version is set to the build version, and OpenIDE-Module-Build-Version is not generated. So, for reproducible builds, we need to solve the OpenIDE-Module-Build-Version 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. So, using git hash feels like a reasonable solution (and we already do that for the build version, only prepend the current date!). 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. Jan On Sun, Aug 4, 2019 at 6:33 AM Emilian Bold wrote: > Using git hash assumes your are building a cloned repository. By > definition this would not work on Apache releases which are just ZIP > files of a given revision. > > It might be simpler to just have a task that generates this stuff and > actually commit it when doing releases (or perhaps, have a bot > periodically commit it). > > --emi > > On Sat, Aug 3, 2019 at 10:06 PM Tim Boudreau wrote: > > > > > It might solve that problem, it doesn't solve this problem! We're > trying to > > > get to a situation where different builds of the same source get the > same > > > implementation versions. > > > > > > > For *that* problem, your best bet is to switch from build numbers to > using > > Git metadata. I do something similar for Maven libraries: > > > https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin > > > > Here is the code that does the heavy lifting: > > > https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java > > > > (in this case it is saving a properties file in META-INF, but easy enough > > to write the same info to a manifest) > > > > The main issues are: > > - You have to assume a local git binary exists, and have some heuristic > > for finding it (if you do this, please don't forget /opt/local/bin for > > those of us that build NetBeans in Jenkins on SmartOS!) > > - You have to assume the local git binary may be old, and not support > some > > of the newer date flags to git log > > - Git's idea of an ISO timestamp is not quite an ISO date as > > Instant.parse() understands it (but you only need the hash here, so this > > probably doesn't matter) > > - If the repository is not clean (no modified sources since the last > > commit or pull), the best you can do is append "-dirty" to the version > name > > and hope things work > > - It might be a good idea to blacklist from update servers any module > > with "-dirty" in its implementation version, to ensure users can actually > > get the bits as compiled > > > > That gets you out of date-stamp land with something that is a more > > dependable indicator of source-state - the git revision hash. > > > > I would strongly suggest *only* doing that for modules that *do not* > > specify an explicit implementation version, but it would certainly be > > better than a build number. That way, nothing that is already specifying > > an implementation version breaks. Or if you want to be even more > > conservative, leave the old build-number behavior on by default, and use > > some switch to turn git hashes on for newly created modules, then > > judiciously go through the sources and turn that switch on for existing > > modules and make sure nothing breaks. > > > > I once played with writing a Java API signature hash generator that used > > javac's API to mow through source code, and did some tricks with mapping > > source elements and character sequences to prime numbers to create a hash > > that only included public method signatures. Something like that would > > probably be a more ideal solution (unless someone writes their API in, > say, > > Groovy - though if it processed .class files instead of sources, that > would > > solve that). > > > > But git hash is pretty good. > > > > -Tim > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Aligning implementation and specification versions?
Using git hash assumes your are building a cloned repository. By definition this would not work on Apache releases which are just ZIP files of a given revision. It might be simpler to just have a task that generates this stuff and actually commit it when doing releases (or perhaps, have a bot periodically commit it). --emi On Sat, Aug 3, 2019 at 10:06 PM Tim Boudreau wrote: > > > It might solve that problem, it doesn't solve this problem! We're trying to > > get to a situation where different builds of the same source get the same > > implementation versions. > > > > For *that* problem, your best bet is to switch from build numbers to using > Git metadata. I do something similar for Maven libraries: > https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin > > Here is the code that does the heavy lifting: > https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java > > (in this case it is saving a properties file in META-INF, but easy enough > to write the same info to a manifest) > > The main issues are: > - You have to assume a local git binary exists, and have some heuristic > for finding it (if you do this, please don't forget /opt/local/bin for > those of us that build NetBeans in Jenkins on SmartOS!) > - You have to assume the local git binary may be old, and not support some > of the newer date flags to git log > - Git's idea of an ISO timestamp is not quite an ISO date as > Instant.parse() understands it (but you only need the hash here, so this > probably doesn't matter) > - If the repository is not clean (no modified sources since the last > commit or pull), the best you can do is append "-dirty" to the version name > and hope things work > - It might be a good idea to blacklist from update servers any module > with "-dirty" in its implementation version, to ensure users can actually > get the bits as compiled > > That gets you out of date-stamp land with something that is a more > dependable indicator of source-state - the git revision hash. > > I would strongly suggest *only* doing that for modules that *do not* > specify an explicit implementation version, but it would certainly be > better than a build number. That way, nothing that is already specifying > an implementation version breaks. Or if you want to be even more > conservative, leave the old build-number behavior on by default, and use > some switch to turn git hashes on for newly created modules, then > judiciously go through the sources and turn that switch on for existing > modules and make sure nothing breaks. > > I once played with writing a Java API signature hash generator that used > javac's API to mow through source code, and did some tricks with mapping > source elements and character sequences to prime numbers to create a hash > that only included public method signatures. Something like that would > probably be a more ideal solution (unless someone writes their API in, say, > Groovy - though if it processed .class files instead of sources, that would > solve that). > > But git hash is pretty good. > > -Tim - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
> It might solve that problem, it doesn't solve this problem! We're trying to > get to a situation where different builds of the same source get the same > implementation versions. > For *that* problem, your best bet is to switch from build numbers to using Git metadata. I do something similar for Maven libraries: https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin Here is the code that does the heavy lifting: https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java (in this case it is saving a properties file in META-INF, but easy enough to write the same info to a manifest) The main issues are: - You have to assume a local git binary exists, and have some heuristic for finding it (if you do this, please don't forget /opt/local/bin for those of us that build NetBeans in Jenkins on SmartOS!) - You have to assume the local git binary may be old, and not support some of the newer date flags to git log - Git's idea of an ISO timestamp is not quite an ISO date as Instant.parse() understands it (but you only need the hash here, so this probably doesn't matter) - If the repository is not clean (no modified sources since the last commit or pull), the best you can do is append "-dirty" to the version name and hope things work - It might be a good idea to blacklist from update servers any module with "-dirty" in its implementation version, to ensure users can actually get the bits as compiled That gets you out of date-stamp land with something that is a more dependable indicator of source-state - the git revision hash. I would strongly suggest *only* doing that for modules that *do not* specify an explicit implementation version, but it would certainly be better than a build number. That way, nothing that is already specifying an implementation version breaks. Or if you want to be even more conservative, leave the old build-number behavior on by default, and use some switch to turn git hashes on for newly created modules, then judiciously go through the sources and turn that switch on for existing modules and make sure nothing breaks. I once played with writing a Java API signature hash generator that used javac's API to mow through source code, and did some tricks with mapping source elements and character sequences to prime numbers to create a hash that only included public method signatures. Something like that would probably be a more ideal solution (unless someone writes their API in, say, Groovy - though if it processed .class files instead of sources, that would solve that). But git hash is pretty good. -Tim
Re: Aligning implementation and specification versions?
I was really looking into this in 2017 https://twitter.com/emilianbold/status/850677972654845952 ... That domain is down but I think I still have the contents in some backup and the patches. The platform was reproducible in my tests, the IDE had some issues with some generated code(/schemas?). NetBeans shouldn't invent reproducible builds but use what https://reproducible-builds.org and https://wiki.debian.org/ReproducibleBuilds are suggesting. Indeed, a given NetBeans release should produce the exact same bits when compiled with the same ant and JDK version. > +1 to reducing the amount of branding changes required on the release branch > (or master tag). But -1 from me to not having any version / branding commits > in the source tree. IMO someone should be able to checkout the sources at any > particular tag / commit and build the "correct" version of the IDE. And that > build shouldn't change over time. I agree with what the above from https://github.com/apache/netbeans/pull/1270 --emi On Sat, Aug 3, 2019 at 8:18 PM Neil C Smith wrote: > > On Sat, 3 Aug 2019, 16:49 Emilian Bold, wrote: > > > NetBeans is in another phase now and the whole desktop IDE/platform space > > is in another place in the industry. NetBeans is being much too > > conservative with its APIs. > > > > I agree with you. I was questioning the idea of people only building on the > platform cluster. As you say, the space is changing. I'd expect overall > number of projects building on our APIs is likely to drop, but as a > percentage those using more than just the platform cluster will rise. Or, > why treat platform cluster APIs differently? > > Anyway, one to solve in another thread? More interested in your thoughts on > the build number / impl version issue given your interest in > reproducibility and/or concerns with your distribution! > > Best wishes, > > Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
On Sat, 3 Aug 2019, 16:49 Emilian Bold, wrote: > NetBeans is in another phase now and the whole desktop IDE/platform space > is in another place in the industry. NetBeans is being much too > conservative with its APIs. > I agree with you. I was questioning the idea of people only building on the platform cluster. As you say, the space is changing. I'd expect overall number of projects building on our APIs is likely to drop, but as a percentage those using more than just the platform cluster will rise. Or, why treat platform cluster APIs differently? Anyway, one to solve in another thread? More interested in your thoughts on the build number / impl version issue given your interest in reproducibility and/or concerns with your distribution! Best wishes, Neil
Re: Aligning implementation and specification versions?
> > Generally we are > too strict with our APIs outside the platform. Nobody is really building > products on top of the other clusters ... > Speak for yourself! ;-) > Actually, if you consider plugins (like Android support), derivative IDEs (like mine) and custom distributions (like yours) these things affect lots of other projects outside of those just using the platform cluster. Well, I do speak for myself and only myself. I think having proper APIs is a guarantee of sorts the project gives users. Still, too restrictive API will make users find "creative" solutions. So by being too rigid in the absolute quality you provide will somehow make things worse overall. NetBeans is in another phase now and the whole desktop IDE/platform space is in another place in the industry. NetBeans is being much too conservative with its APIs. And, interestingly, even people that like conservative APIs get tired of it because if you are stuck on a given version you don't care how easy future migrations are (since they will not happen, really) but start caring more about the lack of customization you can do due to a too tight API surface. --emi sâm., 3 aug. 2019, 15:36 Neil C Smith a scris: > On Sat, 3 Aug 2019 at 12:10, Emilian Bold wrote: > > I support reproducible builds. One simple rule here is to ignore > everything > > from the build environment (date time, server name, build number, maybe > > even git info). Since only release-time versions matter we could > > hardcode/generate all these version strings and only update them as part > of > > the release process. > > If you haven't seen it, perhaps also check out the conversation in > this PR that led me to starting this thread - > https://github.com/apache/netbeans/pull/1270 > > I have some concerns that that proposal, while in the right direction, > is still doing too much in the build environment / outside of the > source tree. Be interested in your perspective. > > > Generally we are > > too strict with our APIs outside the platform. Nobody is really building > > products on top of the other clusters ... > > Speak for yourself! ;-) > > Actually, if you consider plugins (like Android support), derivative > IDEs (like mine) and custom distributions (like yours) these things > affect lots of other projects outside of those just using the platform > cluster. > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Aligning implementation and specification versions?
On Sat, 3 Aug 2019 at 12:18, arsi wrote: > * None of the public/protected methods will be removed in the future Or none of the methods are actually non-private! > Therefore, it is stupid to use a git hash. Git hash isn't stupid - it's one logical way of keeping as much of the existing semantics of implementation version tied to source releases rather than a specific binary build. The proposal to use the spec version is likewise designed to keep as close as possible to the existing semantics (because spec version of every module gets changed for every release currently) I have a lot of sympathy with your issues and wanting to change the semantics / change friend dependencies - I dislike them a lot! But given how much discussion and lack of agreement last time that came up, could we keep it separate to this discussion? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
On Sat, 3 Aug 2019 at 12:10, Emilian Bold wrote: > I support reproducible builds. One simple rule here is to ignore everything > from the build environment (date time, server name, build number, maybe > even git info). Since only release-time versions matter we could > hardcode/generate all these version strings and only update them as part of > the release process. If you haven't seen it, perhaps also check out the conversation in this PR that led me to starting this thread - https://github.com/apache/netbeans/pull/1270 I have some concerns that that proposal, while in the right direction, is still doing too much in the build environment / outside of the source tree. Be interested in your perspective. > Generally we are > too strict with our APIs outside the platform. Nobody is really building > products on top of the other clusters ... Speak for yourself! ;-) Actually, if you consider plugins (like Android support), derivative IDEs (like mine) and custom distributions (like yours) these things affect lots of other projects outside of those just using the platform cluster. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
*From:* Neil C Smith *Sent:* Saturday, August 03, 2019 12:10PM *To:* Dev *Subject:* Re: Aligning implementation and specification versions? Note "git hash"! That would be a different implementation version for every source commit in the repository, even if no code changes in the module. It would mean we have a consistent implementation version across every build of a particular set of sources, rather than changing for every build of that source, nothing more. My question about using spec version loosens this slightly but still gives us unique implementation versions per release/update where required, while having the value in the sources themselves rather than dependent on an "external" source (git hash). I know what you mean, but see. below.. As I have already written, the easiest solution is to manually add the implementation version to each ANB module and manually change them only when changing the public method signatures. This is not what implementation version is for though - it's not about public API. Best wishes, Neil I understand it this way: Public API: Because it can be noted in manifest as *modulule > xx.xx.xx* Author of the module guarantees that: * None of the public API classes will be removed in the future * None of the public/protected methods will be removed in the future * The signature of existing methods will not change in the future * The meaning of the input parameters of the methods will not change in the future * The meaning of the value of the values returned by the method does not change in the future Private API - specification version: In contrast, it is *not guaranteed* that: * None of the classes will be removed in the future * None of the public/protected methods will be removed in the future * The signature of existing methods will not change in the future * The meaning of the input parameters of the methods will not change in the future * The meaning of the value of the values returned by the method does not change in the future If I want to use it it's ok, but I have to note it in the manifest *modulule = xx.xx.xx* *It follows that if none of the above points is changed, there is no reason to change the implementation version. * There are many modules where none of this changes and can be on the same implementation of x ANB releases. Therefore, it is stupid to use a git hash. But one could write a hash implementation that will check those points. But only human can handle the meaning of parameters and return values.. Arsi
Re: Aligning implementation and specification versions?
> It is certainly truth that if Apache does only source releases, then it would be great if two subsequent builds on the same source result in the same bits. I support reproducible builds. One simple rule here is to ignore everything from the build environment (date time, server name, build number, maybe even git info). Since only release-time versions matter we could hardcode/generate all these version strings and only update them as part of the release process. It would also be nice if we would reduce these atypical dependencies in our own codebase. I know there are some impl dependencies on PHP.editor in the PHP cluster which could perhaps become friends at least? Generally we are too strict with our APIs outside the platform. Nobody is really building products on top of the other clusters and they would not complain if we don't offer perfect compatibility. --emi vin., 2 aug. 2019, 14:05 Jaroslav Tulach a scris: > > However, what would be the pros and cons or possibilities of making > > > implementation and specification versions the same? Given we already > > increment all specification versions between releases, this should > > achieve the same purpose for anyone not utilising daily builds? > > > > > http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers > > Implementation version is a free form text. Specification version must be > dewey decimal. Having them be the same means that implementation version > would be equal to dewey's decimal spec version. Could it work? Maybe. > > It is certainly truth that if Apache does only source releases, then it > would be great if two subsequent builds on the same source result in the > same bits. > -jt >
Re: Aligning implementation and specification versions?
On Sat, 3 Aug 2019 at 10:01, arsi wrote: > > > Eric suggested elsewhere using the git hash as build number, which could > > work although might raise other issues. > > Hash is not a bad idea, but it would have to be just a hash of public > method signatures. > > An entire class Hash would cause a new implementation version at any > change in the body of the method, which would be counterproductive.. Note "git hash"! That would be a different implementation version for every source commit in the repository, even if no code changes in the module. It would mean we have a consistent implementation version across every build of a particular set of sources, rather than changing for every build of that source, nothing more. My question about using spec version loosens this slightly but still gives us unique implementation versions per release/update where required, while having the value in the sources themselves rather than dependent on an "external" source (git hash). > As I have already written, the easiest solution is to manually add the > implementation version to each ANB module and manually change them only > when changing the public method signatures. This is not what implementation version is for though - it's not about public API. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
Eric suggested elsewhere using the git hash as build number, which could work although might raise other issues. Hash is not a bad idea, but it would have to be just a hash of public method signatures. An entire class Hash would cause a new implementation version at any change in the body of the method, which would be counterproductive.. As I have already written, the easiest solution is to manually add the implementation version to each ANB module and manually change them only when changing the public method signatures. This will ensure that a plugin will work over x versions of ANB.. Arsi *From:* Neil C Smith *Sent:* Friday, August 02, 2019 11:19PM *To:* Dev *Subject:* Re: Aligning implementation and specification versions? On Fri, 2 Aug 2019, 19:43 Tim Boudreau, wrote: We discussed this long ago, but if you want fewer friend dependencies, then the solution is to get more of those through the API review process and committed to as stable API. That's what it's for, and that's what actually solves the problem. It might solve that problem, it doesn't solve this problem! We're trying to get to a situation where different builds of the same source get the same implementation versions. It's something to consider in moving towards more reproducible builds, and already caused an issue in this release cycle. Eric suggested elsewhere using the git hash as build number, which could work although might raise other issues. Hence wondering whether replacing build number in implementation versions with the same text value as the spec version might work instead. This wouldn't affect anything where the implementation version is set in another way. Best wishes, Neil
Re: Aligning implementation and specification versions?
On Fri, 2 Aug 2019, 19:43 Tim Boudreau, wrote: > We discussed this long ago, but if you want fewer friend dependencies, then > the solution is to get more of those through the API review process and > committed to as stable API. That's what it's for, and that's what actually > solves the problem. > It might solve that problem, it doesn't solve this problem! We're trying to get to a situation where different builds of the same source get the same implementation versions. It's something to consider in moving towards more reproducible builds, and already caused an issue in this release cycle. Eric suggested elsewhere using the git hash as build number, which could work although might raise other issues. Hence wondering whether replacing build number in implementation versions with the same text value as the spec version might work instead. This wouldn't affect anything where the implementation version is set in another way. Best wishes, Neil
Re: Aligning implementation and specification versions?
> NBANDROID uses a special web server, which changes the implementation > version of the dependencies in the modules, but it's not a clean > solution... > And I would like it to be finally resolved. Because it makes module > developers trouble... > Using the build number serves an important purpose: If you are making no compatibility guarantees, then the only thing that's reliable that two libraries are actually compatible is if the answer is "yes" to the question "were both of these things compiled as part of the same build?". Fix that in NBANDROID, not globally. *However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds?* It will break more things than it fixes and just create new problems. Some modules use semi-stable values for implementation version - they aren't official API but they change rarely if at all, and a module built against those will work across releases without someone having to download a new JAR whose only difference may be a dependency version string. Anyone developing a module against those will suddenly start having exactly the problem you want to solve - needing to cut a new release for every increment of the spec version. We discussed this long ago, but if you want fewer friend dependencies, then the solution is to get more of those through the API review process and committed to as stable API. That's what it's for, and that's what actually solves the problem. -Tim
Re: Aligning implementation and specification versions?
Hi, For ANB, I think it's easiest to add implementation versions to all modules. Because currently there are problematic modules that do not have the implementation version. And compiler uses build number as the implementation version. NBANDROID uses a special web server, which changes the implementation version of the dependencies in the modules, but it's not a clean solution... And I would like it to be finally resolved. Because it makes module developers trouble... ArSi *From:* Neil C Smith *Sent:* Friday, August 02, 2019 10:52AM *To:* Dev *Subject:* Aligning implementation and specification versions? Hi, On Sat, 27 Jul 2019 at 05:57, Jaroslav Tulach wrote: Using implementation dependency is a hack of the last resort. It is certainly not something we should encourage. Long time ago there was a discussion about eliminating friend dependencies. We haven't made any changes in the friend dependencies area, but it was clear we see them as problematic. Implementation dependency is way worse. It is at most good for quick and private hacking (actually I am about to use it soon for prototyping). However publishing a plugin NBM with implementation dependency to general consumption is a heresy of the biggest kind. It makes it non-portable across derivatives - CoolBeans, Ideal Graph Visualizer and maybe even Linux distributions! Following on from this, and the re-rolled vote on Maven artefacts for NB 11.1 because of mismatched implementation versions, I was wondering about the best resolution for this going forward. This is not to encourage implementation dependencies any further, although until we do eliminate the annoyance that is friend dependencies (or at least provide ways to externally override) this is going to happen! We should be moving towards more reproducible builds. Having different binary builds of the same sources have different implementation versions is problematic. One option is having the git hash (or similar) be the implementation version. However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: Aligning implementation and specification versions?
Hi, This may not help discussion but the nbm-maven-plugin should maybe also be udpated. It was coded regarding to infra at Oracle time. Maybe some workflow have to be adjusted inside it. I did not get into detail, just make it fit Apache. Regards Eric -Message d'origine- De : Neil C Smith Envoyé : vendredi 2 août 2019 10:52 À : dev Objet : Aligning implementation and specification versions? Hi, On Sat, 27 Jul 2019 at 05:57, Jaroslav Tulach wrote: > Using implementation dependency is a hack of the last resort. It is > certainly not something we should encourage. > > Long time ago there was a discussion about eliminating friend > dependencies. We haven't made any changes in the friend dependencies > area, but it was clear we see them as problematic. > > Implementation dependency is way worse. It is at most good for quick > and private hacking (actually I am about to use it soon for > prototyping). However publishing a plugin NBM with implementation > dependency to general consumption is a heresy of the biggest kind. It > makes it non-portable across derivatives - CoolBeans, Ideal Graph Visualizer > and maybe even Linux distributions! Following on from this, and the re-rolled vote on Maven artefacts for NB 11.1 because of mismatched implementation versions, I was wondering about the best resolution for this going forward. This is not to encourage implementation dependencies any further, although until we do eliminate the annoyance that is friend dependencies (or at least provide ways to externally override) this is going to happen! We should be moving towards more reproducible builds. Having different binary builds of the same sources have different implementation versions is problematic. One option is having the git hash (or similar) be the implementation version. However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
> However, what would be the pros and cons or possibilities of making > implementation and specification versions the same? Given we already > increment all specification versions between releases, this should > achieve the same purpose for anyone not utilising daily builds? > http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers Implementation version is a free form text. Specification version must be dewey decimal. Having them be the same means that implementation version would be equal to dewey's decimal spec version. Could it work? Maybe. It is certainly truth that if Apache does only source releases, then it would be great if two subsequent builds on the same source result in the same bits. -jt
Aligning implementation and specification versions?
Hi, On Sat, 27 Jul 2019 at 05:57, Jaroslav Tulach wrote: > Using implementation dependency is a hack of the last resort. It is certainly > not something we should encourage. > > Long time ago there was a discussion about eliminating friend dependencies. We > haven't made any changes in the friend dependencies area, but it was clear we > see them as problematic. > > Implementation dependency is way worse. It is at most good for quick and > private hacking (actually I am about to use it soon for prototyping). However > publishing a plugin NBM with implementation dependency to general consumption > is a heresy of the biggest kind. It makes it non-portable across derivatives - > CoolBeans, Ideal Graph Visualizer and maybe even Linux distributions! Following on from this, and the re-rolled vote on Maven artefacts for NB 11.1 because of mismatched implementation versions, I was wondering about the best resolution for this going forward. This is not to encourage implementation dependencies any further, although until we do eliminate the annoyance that is friend dependencies (or at least provide ways to externally override) this is going to happen! We should be moving towards more reproducible builds. Having different binary builds of the same sources have different implementation versions is problematic. One option is having the git hash (or similar) be the implementation version. However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
