On Fri, Apr 18, 2014 at 1:31 PM, Kohsuke Kawaguchi <kkawagu...@cloudbees.com> wrote: > We could put both current and the new in the same repo, and call the new one > "perforce plugin 2.0." […] > > We can have alpha/beta releases of 2.0 in parallel to updates to 1.x > releases. People on the beta update center will get this 2.0 beta versions. > When 2.0 is in feature parity, we can have the official 2.0 release.
Is there some advantage of this over my suggestion—to add the new SCM implementation to a single release line of the same plugin, marking the original one as somehow deprecated in labels & help text? There are clearly some disadvantages: · Users will not know they even have the option of using a new system unless they enable the experimental UC, drastically reducing the number of people who will try it. · Users would not be able to try out the new implementation on one or two experimental jobs while leaving more important jobs in a stable configuration. They would have to update the plugin to 2.0 beta <n>, restart Jenkins, then update the configuration of all of their jobs not yet handled by automatic data migration, and hope there are no critical regressions. · Similarly, users deciding that 2.0 is not yet ready would have to deal with downgrading to 1.0 via Plugin Manager (*), restarting Jenkins, then probably reconfiguring all Perforce-based jobs even if they did not use any 2.x features (since 1.x would presumably not be able to read any 2.x data). In a nutshell, I am suggesting to move linearly forward, rather than using branches, making the parallel options available via two SCMDescriptor’s in independent package hierarchies. (*) Which is not straightforward if they went from 1.x to 2.0 beta 1 to 2.0 beta 2, since PM would offer to downgrade only to 2.0 beta 1. They would have to manually download 1.x and install it via the Advanced tab. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
