(replies inline) On Fri, 13 Apr 2018, Carlos Sanchez wrote:
> PR submitted at https://github.com/jenkinsci/jep/pull/83 Related to this work is this pull request which implements extensions to VirtualFile, which I would consider very key to this work: https://github.com/jenkinsci/jenkins/pull/3302 With that pull request there have been some questions raised about how the JEP Workflow interacts with the implementation workflow, and merging of code into plugin and core repositories. I wanted to share the expectations I had in mind when bringing over parts of PEP into JEP-1. The workflow for a Standards JEP is generally going to be Draft->Accepted[0]->Final[1] JEP-1 is somewhat intentionally vague on how these map to merges of pull requests and APIs. My original thoughts around this were that this would be a good thing and allow us the most flexibility in writing code alongside discussing design and APIs, depending on the repository and design. I recognize how this ambiguity also leaves room for confusion. Working backwards, Final is the most clear and obvious in my opinion. A JEP marked as Final means designs and APIs are merged, finalized, and considered "supported" for whatever our hand-wavey-API-support-policy is (i.e. public APIs) in whatever project they're being merged. The requirements for implementation around Accepted[0] much more loosely defined as: "The proposed implementation, if applicable, must be solid, must not complicate Jenkins unduly, and must be the same license as the component the proposal is meant to added to" In the case of Jenkins Essentials, we're merging code regardless of Accepted, or even Draft JEP status, because obviously, that's most expedient given the state of that project. In the case of Jenkins plugins and core which are already being used, I understand that is not the case. However, I think it would be a failure for JEP if we are reluctant to merge code and make _use_ of it before the "Accepted" or "Final" states are reached. To a certain extent I believe that no API or design can be safely considered Final without real world experimental or beta usage. Hiding something behind a feature flag, or a @Beta annotation, for core or plugins is (IMHO) a really good thing to strive for even in the Draft stage to get _real_ usage of designs in the hands of testers and users. All the while, still communicating our intention that these are *beta* (not in the Google sense). The quote "No plan survives contact with the enemy", and my favorite Mike Tyson derivative "Everybody has a plan until they get punched in the mouth" come to mind :) With regards to the pull request for Jenkins core above, my recommendation for the folks working on core is to merge and ship designed, documented, and clearly marked Beta APIs which do not unduly complicate Jenkins, and of course can be safely released and exercised in weekly and LTS releases. I think plugins should be encouraged to follow similar guidelines at their maintainers' discretion. Optimizing for safely trying new things in released versions of code is IMHO a very good thing. Cheers [0] https://github.com/jenkinsci/jep/tree/master/jep/1#accepted [1] https://github.com/jenkinsci/jep/tree/master/jep/1#finalizing-a-jep -- 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/20180420163747.GF1836%40grape.lasagna.io. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
