You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Michael Bien <mb...@gmail.com> on 2022/02/01 10:52:48 UTC
NB 13 tag for plugin portal
Hi,
the plugin portal would need a NB 13 tag soon. Highest version is NB 12.0.
maybe we should remove the .0 from the other tags too?
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 2 Feb 2022 at 14:54, Neil C Smith <ne...@apache.org> wrote:
>
> See what happened for PHP plugins here between
> 12.2 and 12.3 -
Sorry, 12.1 and 12.2.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Michael Bien <mb...@gmail.com>.
On 02.02.22 17:46, Neil C Smith wrote:
> On Wed, 2 Feb 2022 at 16:26, Michael Bien <mb...@gmail.com> wrote:
>> The question here is: how important is the extreme case? Would anyone
>> actually want to branch their plugin and release updates for NB.eol and
>> NB.latest in parallel? Because thats when we really should add multiple
>> catalogs :)
> How does branching come into it? The plugin requiring an API in
> NB.latest (or even NB.next) would become uninstallable in the old
> version immediately it's made available if there's only one catalog?
yes i think so. If a plugin bumps its dependencies it might no longer be
installable on some older NB installations. But a maintainer could also
decide to not bump the dependencies if there is that option and stay
compatible for a while.
By branching i mean having multiple catalogs. I think this would make
sense if we would also allow maintainers to push updates to old
catalogs. Therefore branch their plugin version into a LTS scheme (even
though NB does not have a LTS scheme).
but that would be extra work (who wants that :))!. Maybe we can just
live with one catalog now that NB does not have LTS versions? (+ the
NB.next/daily etc you mentioned)
I really don't have strong feelings about this btw. I just think we
should not make it more complex unless there are good reasons.
>> And btw i believe there is still the option of a "custom update center"
>> for anyone who needs full control over it, right?
> Yes.
>
>> I think i had that
>> over a decade ago for the NB GL and CL packs
> Hadn't realised that was you! Did look at that when I was working on
> some GLSL editing features.
small world :)
the GLSL editor (of the super old "NetBeans OpenGL Pack") used
"schlieman" (now unmaintained) for editor support and parsed compiler
msgs of the graphics driver for the error badges. The OpenCL editor used
a proper antlr grammar based on the C grammar, and used JOCL (which i
wrote too btw ;)) as binding to the OpenCL impl.
https://mbien.dev/blog/entry/netbeans_opencl_pack
https://mbien.dev/blog/entry/java_binding_for_the_opencl
best regards,
-michael
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 2 Feb 2022 at 16:26, Michael Bien <mb...@gmail.com> wrote:
> The question here is: how important is the extreme case? Would anyone
> actually want to branch their plugin and release updates for NB.eol and
> NB.latest in parallel? Because thats when we really should add multiple
> catalogs :)
How does branching come into it? The plugin requiring an API in
NB.latest (or even NB.next) would become uninstallable in the old
version immediately it's made available if there's only one catalog?
> And btw i believe there is still the option of a "custom update center"
> for anyone who needs full control over it, right?
Yes.
> I think i had that
> over a decade ago for the NB GL and CL packs
Hadn't realised that was you! Did look at that when I was working on
some GLSL editing features.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Michael Bien <mb...@gmail.com>.
On 02.02.22 16:34, Neil C Smith wrote:
> On Wed, 2 Feb 2022 at 15:07, Michael Bien <mb...@gmail.com> wrote:
>> There was only "latest", the
>> version scheme change makes that more obvious.
> Yes. it was the use of "series" and "point release" ;-)
>
>> how can this happen again without a concept of LTS? Can you give an example.
>>
>> If a plugin maintainer upgrades a plugin and that upgrade causes it to
>> only work on NB 13+. It should not be installable/upgradable in any EOL
>> release before NB 13 - even if its in the same catalog.
> OK, I get what you mean. I've been assuming we'd want at least an
> overlap of previous and current? Do we want an updated plugin catalog
> available for daily builds and RCs before release, and I'm not sure
> everyone wants to update immediately on release? Do we want plugins
> to be verified in any way? Or maybe just hidden on reports that they
> stop working?
I mean my example was an extreme case. I don't think this would be the
general case. Its in the interest of the plugin maintainers too to not
break things right away - but if they want or have to for some reason -
i think its fine too. It would only mean that there won't be any updates
to already installed versions of that particular plugin on EOL NB
installations.
The general case would be that It is likely that plugins will remain
compatible for a while even when you don't update NB right after release.
The question here is: how important is the extreme case? Would anyone
actually want to branch their plugin and release updates for NB.eol and
NB.latest in parallel? Because thats when we really should add multiple
catalogs :)
And btw i believe there is still the option of a "custom update center"
for anyone who needs full control over it, right? I think i had that
over a decade ago for the NB GL and CL packs back when java.net was
still around. (maybe the plugin portal 1.0 didn't exist yet?)
> Also, just because we EOL doesn't necessarily equate to a release
> being EOL everywhere. Whether we want to support plugins for other
> distributions is another matter, or whether many still exist anyway.
If there is a distribution which packages NB 13 and doesn't upgrade it
for the next 5 years. There is not a lot we can do about this (unless we
let NB upgrade itself) - some plugins won't be upgradable/installable
after a while.
best regards,
michael
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 2 Feb 2022 at 15:07, Michael Bien <mb...@gmail.com> wrote:
>
> There was only "latest", the
> version scheme change makes that more obvious.
Yes. it was the use of "series" and "point release" ;-)
> how can this happen again without a concept of LTS? Can you give an example.
>
> If a plugin maintainer upgrades a plugin and that upgrade causes it to
> only work on NB 13+. It should not be installable/upgradable in any EOL
> release before NB 13 - even if its in the same catalog.
OK, I get what you mean. I've been assuming we'd want at least an
overlap of previous and current? Do we want an updated plugin catalog
available for daily builds and RCs before release, and I'm not sure
everyone wants to update immediately on release? Do we want plugins
to be verified in any way? Or maybe just hidden on reports that they
stop working?
Also, just because we EOL doesn't necessarily equate to a release
being EOL everywhere. Whether we want to support plugins for other
distributions is another matter, or whether many still exist anyway.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Michael Bien <mb...@gmail.com>.
On 02.02.22 15:54, Neil C Smith wrote:
> On Wed, 2 Feb 2022 at 14:42, Michael Bien <mb...@gmail.com> wrote:
>> i mean there is only 12.6 in the 12.x series in my book - nobody should
>> spend time testing something on 12.1 right now for example IMO.
> ...
>> I think one reason for the new versioning scheme was to show that there
>> is only one supported version at a time.
> There never was a 12.x series! There were no "point releases". There
> is zero difference between upgrading 12.5 -> 12.6 as between 12.6 ->
> 13. The only thing the "major" increment differentiated was new LTS,
> which we no longer have anyway.
>
> The main reason I proposed the version scheme change is that still
> no-one understood it! :-)
yes exactly. There was no LTS anyway. There was only "latest", the
version scheme change makes that more obvious.
>> I don't know the details how the module upgrades work. But having only
>> one catalog sounds like the simpler solution (i like simple).
> Simple is per-release. See what happened for PHP plugins here between
> 12.2 and 12.3 -
> https://lists.apache.org/thread/bnk1dg8dcnq1bslq2dvs1grv5hvzgdtm That
> problem will reoccur.
how can this happen again without a concept of LTS? Can you give an example.
If a plugin maintainer upgrades a plugin and that upgrade causes it to
only work on NB 13+. It should not be installable/upgradable in any EOL
release before NB 13 - even if its in the same catalog.
-mbien
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 2 Feb 2022 at 14:42, Michael Bien <mb...@gmail.com> wrote:
> i mean there is only 12.6 in the 12.x series in my book - nobody should
> spend time testing something on 12.1 right now for example IMO.
...
> I think one reason for the new versioning scheme was to show that there
> is only one supported version at a time.
There never was a 12.x series! There were no "point releases". There
is zero difference between upgrading 12.5 -> 12.6 as between 12.6 ->
13. The only thing the "major" increment differentiated was new LTS,
which we no longer have anyway.
The main reason I proposed the version scheme change is that still
no-one understood it! :-)
> I don't know the details how the module upgrades work. But having only
> one catalog sounds like the simpler solution (i like simple).
Simple is per-release. See what happened for PHP plugins here between
12.2 and 12.3 -
https://lists.apache.org/thread/bnk1dg8dcnq1bslq2dvs1grv5hvzgdtm That
problem will reoccur.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Michael Bien <mb...@gmail.com>.
On 02.02.22 14:55, Neil C Smith wrote:
> On Tue, 1 Feb 2022 at 10:54, Michael Bien <mb...@gmail.com> wrote:
>> the plugin portal would need a NB 13 tag soon. Highest version is NB 12.0.
>>
>> maybe we should remove the .0 from the other tags too?
> Well, it's no more or less of a problem than the missing 12.1 -> 12.6! :-)
>
> There have already been plugins that weren't compatible across that
> range.
i mean there is only 12.6 in the 12.x series in my book - nobody should
spend time testing something on 12.1 right now for example IMO.
A NB 12 tag would imply 12.6. With NB 13 the point releases are gone anyway.
But looking at the redirect list... its probably better to not touch the
old .0 tags, the list is big enough (even though having 12.0 next to 13
can look confusing).
I don't know the details how the module upgrades work. But having only
one catalog sounds like the simpler solution (i like simple). If a
plugin has the module dependencies properly set, it won't install on old
NB installations, right? It also shouldn't appear as an update
suggestion - hopefully. (if it does we could probably fix this in NB I
suppose)
I think one reason for the new versioning scheme was to show that there
is only one supported version at a time and encourage upgrades. Versions
become meaningless. (example: I don't even know which firefox version i
have installed, but I do know its the latest)
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB 13 tag for plugin portal
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 1 Feb 2022 at 10:54, Michael Bien <mb...@gmail.com> wrote:
> the plugin portal would need a NB 13 tag soon. Highest version is NB 12.0.
>
> maybe we should remove the .0 from the other tags too?
Well, it's no more or less of a problem than the missing 12.1 -> 12.6! :-)
There have already been plugins that weren't compatible across that
range. We really need to be able to tag per release, and a catalog
per release, so we can stop having each individual redirect ending in
the same place! See eg.
https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess#L29
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists