I don’t know why everyone is trying to pitch NetBeans back to be a Java IDE? It can even more. Problematic again is also the other APIs for HTML/CSS/JS they are not public by default. Everything is as stable as possible now. Make them open and let people like me contribute to the other parts of the IDE. Everything is working for years now.
Yes, NetBeans don’t need more Bugs but it has bugs like every other software 😃 so what will be the solution for that? Ignoring Bugs of NetBeans? Seems so. So I’m totally against to couple the version to the JDK Version. Don’t set the focus back to Java to this awesome IDE. Cheers Chris Von: Eric Bresie Gesendet: Sonntag, 26. September 2021 18:44 An: Netbeans Developer List Betreff: Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5 I know since Netbeans IDE is java centric, it is by no means specific to Java and linking to java version may be valuable to java developers but may not be for those for other languages. Think that has been discussed before but I'm going to throw it out just in case... Would it be worth changing the number to date based versions like other folks have (i.e. yyyy-mm, or some "quarterly" based nomenclature [i.e. 2021-Q3 or Q4])? Eric Bresie ebre...@gmail.com On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <jaroslav.tul...@gmail.com> wrote: > > >> This essentially makes release numbers meaningless, which seems to be > the > > >> way things are going... > > There is a difference between "marketing" release number and "engineering" > release numbers. Marketing release numbers are meaningless - it doesn't > matter > whether it is going to be NetBeans 13, 14, or 12.6, 12.7 - it's just a > marketing campaign. > > Engineering numbers are more important when it comes to discussion whether > a > plugin works with certain system version or not. A scientific take on that > can > be found at my website: > > http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed > > NetBeans Module System allows you to easily specify the "lower bound". Do > it. > There is also an implicit "upper bound" - restricted by the same major > release number, but Apache NetBeans project avoids changing the major > release > number as much as possible and rather we keep (signature based) > compatibility. > > In any case my advice is: Upload to update center. Specify the lower > bound. > Open up the "upper bound" as much as possible, unless it is known there is > a > problem in "future versions". In such case restrict the upper bound or > rather > report and fix the problem in NetBeans code itself. > > > > >> There is a, perhaps, unintended consequence. The plugins I support > have > > >> continued to work, and be available in the plugin manager, through all > > >> of 12.x without any effort on my part. > > That's result of the hard work of Apache NetBeans contributors and release > managers! Everyone pays attention to "sigtest" signatures and as such we > don't > have linkage problems (so common in Oracle NetBeans) and even runtime > problems > are rare. > > > > The before times update center required a new plugin download for every > > NB release. The netbeans.apache update center is friendlier since you > > can specify which /major/ releases a plugin works with; so it's not > > dependent on a NB minor release, and you can specify multiple NB > > releases. But it's easily possible that going from 12.2 to 12.3 a plugin > > needs to be changed, but there's no way to specify that in the update > > center, for example see > > https://issues.apache.org/jira/browse/NETBEANS-5064 which demonstrates > > that the current association of NB-version with plugin is broken. > > Repeat: marketing numbers (12.2 and 12.3) are useless. Only the > engineering > numbers make (some) sense. E.g. watch for individual module dependencies. > > > The old method of tying a full version number to a plugin is more > > reliable. > > Of course. Only "no flexibility" (in version dependencies) allows some > form of > certification - that's the approach QA guys like. However... > > > But with 4 releases a year there's more overhead, not only for > > plugin developers, but for doing plugin verification. > > ... as we are short on time and resources, we'd rather worship "semantic > versioning" and understand proximity: > http://wiki.apidesign.org/wiki/Proximity > > > Some way to loosely couple seems desirable. If the portal had a list of > > all version numbers, and spec'ing vers-X means "vers-X and all later > > releases, up to the next spec'd" would do the trick. > > > > > If we want version numbers to be meaningful, > > > > NetBeans might the the prime example of where semantic versioning would > > not work well. > > NetBeans versioning scheme has been designed before semantic versioning > website was created. There may be some differences, but in general, I > suggest > to follow semantic versioning and think about proximity. > > > Each NB module has it's own version number. > > > > jVi was compatible with NB-7.* and NB-8.*. In module restore, jVi > > checked each module it cared about and set some flags to control > > behavior; > > Clever. > > > a hassle but easier than having different plugin versions for > > each NB version, especially when it comes to features and bug fixes (I > > wasn't comfortable with saying you had to use the latest NB version). > > Obviously. It is desirable to offer a system when one jVi module can work > with > all (released/marketing) versions NetBeans IDE since some "lower bound". > > > BTW, when I said "release numbers meaningless, which seems to be the way > > things are going" I was referring to the industry, thinking > firefox/chrome. > > If you invest into pushing users to the latest version (like browsers or > iOS > does), then you simplify the burden of supporting old versions for > everyone. A > question remains: what poor users that cannot run the latest version (of > iOS > like me) shall do? > > > > I suggest an attempt at something as close as possible to semantic > > > versioning: https://semver.org Then plugin compatibility can be > inferred > > > from the major version number, and if that changes it’s because you > > > really do need to check more than metadata to see if your plugin > remains > > > compatible. > > (Engineering) versioning shall remain per module. It stresses the idea > that > NetBeans Platform is like LEGO - you can select the pieces (that fit > together > thanks to the versioning) and assemble anything you like. > > > > If NetBeans moves the required JRE/JDK to 11 or later that would make > now > > > the time to bump the major version to 13 or later. > > Again, 13 is a marketing number. Do whatever you want with it, but don't > interchange it with engineering numbers and compatibility, please! > > -jt > > > > > --------------------------------------------------------------------- > 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 > > > >
