THE Java IDE? Where did I post that? Gj
On Mon, 27 Sep 2021 at 13:32, Christian Lenz <[email protected]> wrote: > That doesn’t matter if you set the focus back to Java more and more. You > post about NetBeans as THE Java IDE. What is your goal with that? Next time > you will post about „NetBeans now has a new Version politic which is in > line with new JDK version“. Wow. > > Again, this is my pov and I’m for those versioning what we have or more an > other one with will be in line with the year like Apache NetBeans 2022.1 – > 2022.4. But we had this discussion already. > > Von: Geertjan Wielenga > Gesendet: Sonntag, 26. September 2021 20:20 > An: dev > Betreff: Re: Release numbers, ranges, semantic versioning, etc. > was:Postmortem 12.5 > > 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 > > > > > > > > > > > > > > > > > >
