NetBeans can support all the languages and technologies of the world while still being coupled to JDK versions...
Gj On Sun, Sep 26, 2021 at 7:48 PM Christian Lenz <[email protected]> wrote: > 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 > [email protected] > > > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <[email protected] > > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > >
