So, you've proven it, I did not say THE Java IDE. Indeed, it is an IDE written in Java, in that sense it is a Java IDE.
Gj On Mon, Sep 27, 2021 at 2:30 PM Christian Lenz <[email protected]> wrote: > https://twitter.com/netbeans/status/1435687644705529866 > > I guess you are mainly behind the twitter account of NetBeans also behind > the Facebook page of NetBeans, but sure could be someone else. But > @netbeans still exists before Apache so. If not, I’m sry, but again someone > tries to set the Focus wrong IMHO. > > Von: Geertjan Wielenga > Gesendet: Montag, 27. September 2021 13:34 > An: [email protected] > Betreff: Re: Release numbers, ranges, semantic versioning, etc. > was:Postmortem 12.5 > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
