Hi all, Note that there are some features in addition to semantic versioning. See https://wiki.jenkins.io/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions.Jenkins itself considers only minimal compatible versions in its metadata (Core 1.625+ or plugin foo 2.3+), there is no way to define upper bounds now. We could do it, but it would require significant changes as noted above.
Also, there are ways to just set upper bounds checks so that we ensure that transient dependencies are compatible. For example, Plugin A depends on Plugin C 1.0, and Plugin B depends on Plugin C 2.0. When Plugin A and Plugiun B are installled, we need to ensure that a right version of plugin C is installed (2.0). When we were talking about the goal, it was my understanding of this bullet IIRC BR, Oleg On Friday, May 17, 2019 at 10:25:17 PM UTC+2, slide wrote: > > While this would be great, it will be VERY difficult to do across all the > plugins. Some plugins that are used by people don't even have maintainers. > How does the install wizard do this? I believe it just uses the normal > dependency information that is in the plugins that are selected. I would > say it is not in the scope of this project as it would require a large > change across thousands of plugins. > > On Fri, May 17, 2019 at 1:15 PM Natasha Stopa <[email protected] > <javascript:>> wrote: > >> Here was a conversation with Joseph Peterson that I wanted to pull out >> from the proposal doc. In the document, I had originally put that one of >> the requirements was that "the library must make sure that versions of >> required dependencies are compatible." >> >> Joseph: "This seems like an impossible task unless plugins follows >> something like semantic versioning" >> >> >> >> Me: "Hi Joesph, could you explain a little more? Are you saying that this >> is generally an unrealistic goal, or that semantic versioning is the way to >> go? Is semantic versioning used in other places in Jenkins or would an >> implementation using semantic versioning be a new change? Are there >> downsides to using a semantic versioning approach?" >> >> >> >> Joseph: "Yes, it seems like an unrealistic goal unless all plugins devs >> could agree that we have to rely on semantic versioning. At least for this >> project, you would need a way to mark plugins as incompatible or a way to >> analyze each plugin's dependency and then analyze for potential binary >> compatibility. >> >> >> >> With semantic versioning, you could rely on a plugins's dependency having >> different major version to tell you whether the dependencies are compatible" >> >> >> >> So I wanted to get some feedback on semantic versioning. Is this >> something plugin devs would be interested in? Is that something that's >> totally out of scope or not worth looking into for this project? >> >> >> >> >> On Friday, May 17, 2019 at 1:36:16 PM UTC-4, Natasha Stopa wrote: >>> >>> Hi everyone, >>> I'm Natasha Stopa and I'm currently a Master's student in CSE at Penn >>> State. I was accepted to Google Summer of Code 2019 for a project for a >>> plugin installation manager/CLI. The goal of this project is to unify the >>> existing implementations of plugin managements into one library and create >>> new Plugin Manager CLI tools. >>> >>> The project page can be found here: >>> >>> https://jenkins.io/projects/gsoc/2019/plugin-installation-manager-tool-cli/ >>> I'll be updating this page frequently as the summer goes on, but it >>> currently has some nice information about the existing implementations. >>> >>> My project proposal can be found here: >>> >>> https://docs.google.com/document/d/1lMCDqY5TKVXyFl67BmyMkaS9GTjRbueKr7ds395b_10/edit?usp=sharing >>> Feel free to comment and give feedback. I will be pulling some of the >>> already received comments out of that document and into the mailing list so >>> that it will be easier to follow and discuss with the community. >>> >>> Lastly, the project gitter channel can be found here: >>> https://gitter.im/jenkinsci/plugin-installation-manager-cli-tool >>> >>> I'm still working on the design and learning about Jenkins and would >>> love your comments and feedback. Do you have questions or concerns about >>> the current plan? How do you envision the library and tool being used? >>> What features do you think should be included? Are there details you think >>> are missing or need to be hashed out more? >>> >>> Thanks and I'm looking forward to hearing from you and working with you >>> this summer! >>> >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/6cd8a2c4-d48c-45ef-b3f6-9f1c804a2fde%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/6cd8a2c4-d48c-45ef-b3f6-9f1c804a2fde%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Website: http://earl-of-code.com > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ffe4534a-e0da-4d35-b028-0bd8059b3099%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
