[
https://issues.apache.org/jira/browse/NETBEANS-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420081#comment-17420081
]
Jaroslav Tulach edited comment on NETBEANS-5064 at 9/25/21, 7:58 AM:
---------------------------------------------------------------------
The NetBeans IDE versions are meaningless from an engineering perspective. If
we want to simplify life of plugin writes (and we should), then I suggest to
support many range dependencies:
[http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed] to quote:
{quote}Should there be a repository of modules and their
[dependencies|http://wiki.apidesign.org/wiki/Dependencies] including module _M_
in versions 1.1,1.2,1.5,2.0,2.5,3.0. If majority of other modules having a
dependency on _M_ uses range [1.1,2.0) (e.g. the classical range for [semantic
versioning|http://wiki.apidesign.org/wiki/Semantic_versioning]), then we can
deduce that the owner of module _M_ is doing good job keeping
[BackwardCompatibility|http://wiki.apidesign.org/wiki/BackwardCompatibility].
If many dependencies on _M_ use for example [1.1,1.5), then we can deduce that
something unnatural (from the point of [semantic
versioning|http://wiki.apidesign.org/wiki/Semantic_versioning] happened in
version 1.5) and that the owner of the module _M_ underestimated the impact of
changes in version 1.5. On the other hand, if many dependencies on _M_ use
range like [1.1,3.0) then the
[incompatible|http://wiki.apidesign.org/wiki/Incompatible] change was probably
not as [incompatible|http://wiki.apidesign.org/wiki/Incompatible] as it might
have seen.
{quote}
Let, for each published NBM, allow the author to specify the (essential)
dependencies on some modules from NetBeans IDE distribution and the supported
ranges. Lower bound (that's in the NBM's JAR manifest anyway) and an upper
bound (implicit to major module version, but let module writers restrict it
even more).
The module catalog for a version of NetBeans IDE should then offer all NBMs
that have their dependencies (lower and upper bounds) satisfied.
was (Author: jtulach):
The NetBeans IDE versions are meaningless from an engineering perspective. If
we want to simplify life of plugin writes (and we should), the I suggest to
support many range dependencies:
[http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed] to quote:
{quote}Should there be a repository of modules and their
[dependencies|http://wiki.apidesign.org/wiki/Dependencies] including module _M_
in versions 1.1,1.2,1.5,2.0,2.5,3.0. If majority of other modules having a
dependency on _M_ uses range [1.1,2.0) (e.g. the classical range for [semantic
versioning|http://wiki.apidesign.org/wiki/Semantic_versioning]), then we can
deduce that the owner of module _M_ is doing good job keeping
[BackwardCompatibility|http://wiki.apidesign.org/wiki/BackwardCompatibility].
If many dependencies on _M_ use for example [1.1,1.5), then we can deduce that
something unnatural (from the point of [semantic
versioning|http://wiki.apidesign.org/wiki/Semantic_versioning] happened in
version 1.5) and that the owner of the module _M_ underestimated the impact of
changes in version 1.5. On the other hand, if many dependencies on _M_ use
range like [1.1,3.0) then the
[incompatible|http://wiki.apidesign.org/wiki/Incompatible] change was probably
not as [incompatible|http://wiki.apidesign.org/wiki/Incompatible] as it might
have seen.
{quote}
Let, for each published NBM, allow the author to specify the (essential)
dependencies on some modules from NetBeans IDE distribution and the supported
ranges. Lower bound (that's in the NBM's JAR manifest anyway) and an upper
bound (implicit to major module version, but let module writers restrict it
even more).
The module catalog for a version of NetBeans IDE should then offer all NBMs
that have their dependencies (lower and upper bounds) satisfied.
> Support for specific NB (feature release) versions
> --------------------------------------------------
>
> Key: NETBEANS-5064
> URL: https://issues.apache.org/jira/browse/NETBEANS-5064
> Project: NetBeans
> Issue Type: Wish
> Components: updatecenters - Pluginportal
> Reporter: Junichi Yamamoto
> Priority: Major
>
> Maybe, currently, URLs for feature versions(e.g. 12.1) are redirected to the
> URL for the LTS(e.g. 12.0) version, right?
> That has a problem. We can't use an nbm of the LTS version if a feature
> version has incompatible changes.
> There are incompatible changes for PHP support in NetBeans 12.2. So, some
> plugins related to PHP don't work any longer in 12.2 with the nbm for 12.0.
> So, I have to provide nbms for 12.2. However, we can't add them to PP at the
> moment. So, I have to upload them to another place(e.g. GitHub).
> It would be nice for users/developers if we can add nbms for specific
> versions. OTOH, it may be hard work for verifiers(/developers) to
> verify(/add) them...
> e.g. Although I'm not sure whether it is possible, if there is no nbm of
> specific versions, it would be nice to be able to use nbms of LTS versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
