[ 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