[GSOC 2019] Plugin Installation Manager/CLI Introduction

8 views
Skip to first unread message

Natasha Stopa

unread,
May 17, 2019, 1:36:16 PM5/17/19
to jenkin...@googlegroups.com
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: 
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: 
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: 

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! 



Natasha Stopa

unread,
May 17, 2019, 4:15:37 PM5/17/19
to Jenkins Developers
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?

Slide

unread,
May 17, 2019, 4:25:17 PM5/17/19
to jenkin...@googlegroups.com
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.

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6cd8a2c4-d48c-45ef-b3f6-9f1c804a2fde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Website: http://earl-of-code.com

Oleg Nenashev

unread,
May 18, 2019, 5:08:28 AM5/18/19
to Jenkins Developers
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
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages