On Mon, Aug 25, 2014 at 5:23 PM, Slide <[email protected]> wrote: > I notice that the work is being done in a separate branch. I would > still prefer that any work be done in someone's own fork and pull requests > created for any desired updates.
Sure. BTW it is possible (and sometimes useful) to file PRs from a branch in the original repo, since it allows for easier collaboration on the branch. On the topic of parent POM version: dealing with new APIs is somewhat awkward currently since the jenkins-ci.org update center infrastructure is pretty dumb, and can only generate distinct update centers for three conditions: · newest plugin release (i.e., experimental UC) · newest plugin release not -alpha or -beta (i.e., regular UC) · newest plugin release compatible with currently newest LTS line (i.e., LTS UC) (CloudBees offers another set of public UCs that are more easily switched to different criteria but follow basically the same model.) Therefore you can release a plugin depending on a new (post-LTS) core but it will appear for a lot of other users—with a warning, but there is no option to get a *different* update. To work around this I have been releasing a few plugins to the experimental UC when their core dep is after current LTS, so they are at least hidden from most users. What would really be nicer is if you could just do plugin releases whenever you like and the plugin manager in Jenkins would always show you the most recent version compatible with *your* core, whatever that is, including random weeklies or older LTS lines. One long-term option is to make core accept UC metadata listing multiple plugins with different dependencies, and intelligently display one or more options in the update UI. But the easier option would be to fix the UC server to pay attention to ?version=… and compute compatible plugins accordingly; note that this means the UC site cannot be a static file, though it could cache the UC per version for efficiency. In any event, physically releasing different release trains of a plugin is quite easy; you need only have a branch for compatibility with an older core version, and ‘git cherry-pick -x’ important fixes to it. (There are other models that would let you use true ‘git merge’, which is more robust than cherry-picking, though it is a little tricky since release commits will be merge conflicts.) ‘mvn -B release:prepare release:perform’ works properly on whichever branch you have checked out. -- 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]. For more options, visit https://groups.google.com/d/optout.
