I didn't realize that you could release two versions of a plugin at the same time to two different update centers. I think your proposal is probably the best option here.
On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi < [email protected]> wrote: > > I'm waiting for Rob and Paul to agree on the approach forward. I think > we'd be happy to honor that, since you guys are the ones that are doing the > actual work. > > > Where Jesse and I are coming from is to try to understand the message to > the existing users, because Perforce plugin is widely used. > > > If you expect both current and new plugins to co-exist going forward, > that's the least preferable outcome from users' PoV. > > The next better one is that you expect the current plugin to become > dormant and all the efforts to go to the new plugin. It's still disruptive > for users, but at least there's a clarity in the direction. > > The next better one is that you two agree that the current plugin will > become dormant and the new one will take over, then we work out the data > migration compatibility between the current and new plugin, without > preserving code compatibility. This is pretty good for users, as they don't > have to go through disruptive changes. > > Then the final one is to try to maintain some/all of the code > compatibility. If there are plugin out there that depends on the perforce > plugin, this will make their users happy. > > > Without much experience of Perforce, what I'd like to encourage you to > consider is the third option, and here is one way of doing it. > > We could put both current and the new in the same repo, and call the new > one "perforce plugin 2.0." They need not share the code at all. 2.0 would > work toward feature parity with 1.0. Existing Jenkins devs can help create > migration shim in the 2.0 branch. > > 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. > > Or if we discover that feature parity is unattainable, we can rename the > new version to another name and release it as a separate plugin. > > > > > On 04/18/2014 02:33 AM, Paul Allen wrote: > >> Hi Rob, >> >> The refactoring effort would be so wide spread there would be very >> little, if anything, left. >> >> By removing the underlying p4 command wrapper (Tek42) and replacing it >> with the p4-java api would require a re-write of all the functions. In >> addition the behavioural changes to the use of Perforce workspaces and >> authentication would change most of the user interface. >> >> I suggest that we either create a new plugin 'p4' or fork/rename the >> existing plugin. A new plugin would be less disruptive to the existing >> user base and give the opportunity for a clean start. >> >> Paul >> >> On 17 Apr 2014, at 19:23, Rob Petti <[email protected]> wrote: >> >> I thought it was decided that refactoring the old plugin was the better >>> way to go? It's less of an impact on users, and preserves all of the >>> required functionality. >>> >>> If not, then just make a new repo, I guess... >>> >>> On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: >>> I have been discussing the plugin for sometime over email. >>> >>> I'll CC Rob and the others... >>> >>> Paul >>> >>> On 17 Apr 2014, at 16:59, Jesse Glick <[email protected]> wrote: >>> >>> > On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen <[email protected]> >>> wrote: >>> >> Whilst the new plugin provides all the basic SCM functions, it is not >>> yet as feature rich. We plan to add features [...] >>> >> >>> >> [...] perhaps there is a way to branch (fork) the old codebase into a >>> legacy area? >>> >>> > >>> > A bit more work, but arguably better for users, would be to include >>> > the new refactored implementation inside the existing plugin (in trunk >>> > versions). For a time, users of the plugin would see two SCM >>> > options--Perforce (v1) and Perforce (v2)--with somewhat different >>> >>> > configuration UIs and functionality. They could experiment with >>> > switching to v2, or go back for a while, on a project-by-project >>> > basis. You could even decide that v1 configurations restricted to a >>> > certain set of commonly used features would be safe to automatically >>> > upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1 >>> > implementation could be dropped, or rather exist only as a class with >>> > a readResolve method. >>> > >>> > This is of course assuming that the current maintainer(s) of >>> > perforce-plugin are aware of your effort and on board with it. >>> > >>> > -- >>> > 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. >>> >>> >>> >>> ------------------------------------------------------------ >>> -------------------- >>> This email and any files transmitted with it are confidential and >>> intended >>> solely for the use of the individual or entity to whom they are >>> addressed. If >>> you have received this email in error please notify the system manager. >>> Please >>> note that any views or opinions presented in this email are solely those >>> of the >>> author and do not necessarily represent those of Perforce Software. >>> Finally, >>> the recipient should check this email and any attachments for the >>> presence of >>> viruses. Perforce Software accepts no liability for any damage caused by >>> any >>> virus transmitted by this email. >>> >>> Perforce Software UK Ltd is registered in England and Wales as company >>> no. >>> 3816019 at the following address: West Forest Gate, Wellington Road, >>> Wokingham, >>> RG40 2AT, UK >>> ------------------------------------------------------------ >>> -------------------- >>> >>> -- >>> 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. >>> >> >> >> >> ------------------------------------------------------------ >> -------------------- >> This email and any files transmitted with it are confidential and intended >> solely for the use of the individual or entity to whom they are >> addressed. If >> you have received this email in error please notify the system manager. >> Please >> note that any views or opinions presented in this email are solely those >> of the >> author and do not necessarily represent those of Perforce Software. >> Finally, >> the recipient should check this email and any attachments for the >> presence of >> viruses. Perforce Software accepts no liability for any damage caused by >> any >> virus transmitted by this email. >> >> Perforce Software UK Ltd is registered in England and Wales as company no. >> 3816019 at the following address: West Forest Gate, Wellington Road, >> Wokingham, >> RG40 2AT, UK >> ------------------------------------------------------------ >> -------------------- >> >> > > -- > Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ > Try Jenkins Enterprise, our professional version of Jenkins > -- 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.
