good question. Here are some options: 1. last release used in Maven 3.3.9, ie Aether 1.0.2.v20150114 sha1 8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e [1], that is currently HEAD of 1.0.x branch
2. code imported to Apache, that I tagged as aether-core-import in master sha1 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b [2], 1.1.0-SNAPSHOT Notice that I don't precisely know what is different from 1.0.2.v20150114 3. the last commit before changes that go beyond gav partial updates (because changes were done before import vote was finished) sha1 11a061b66fd15b8c3584f48afa69955d9392861e [3] The biggest question is: what is the precise impact of 1.0.2 vs 1.1.0- SNAPSHOT? I personnally don't know Regards, Hervé [1] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/ 8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/ 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b [3] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/ 11a061b66fd15b8c3584f48afa69955d9392861e Le vendredi 30 décembre 2016, 13:54:58 CET Stephen Connolly a écrit : > What hash do we want to reset resolved to? > > (We will be *renaming* master in all cases so that the history is > available... just not on master) > > On Fri 30 Dec 2016 at 08:02, Robert Scholte <[email protected]> wrote: > > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <[email protected]> > > > > wrote: > > > perhaps maven-resolver will require same reset > > > > +1 > > > > > > > > IMO we forgot to do a release with the original Aether code with the new > > > > > > > > GAVs. > > > > > > > > Robert > > > > > and we'll need to define which convention to use on Jira when merging > > > > > > code: > > > > > > remove "Fix Version: 3.4.0" for example, to track what features have not > > > > > > been > > > > > > merged yet > > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit : > > >> On ASF infra, our master branch is supposed to be a protected branch > > >> and > > >> > > >> thus cannot be reset or force-pushed without an INFRA ticket. > > >> > > >> > > >> > > >> If we want to reset our master branch in order to clean out the history > > >> > > >> of > > >> > > >> the many changes and reverts to and fro etc, we thus need an INFRA > > >> > > >> ticket > > >> > > >> raised. > > >> > > >> > > >> > > >> INFRA should not act on such a ticket without the results of a vote of > > >> > > >> the > > >> > > >> committers that has at least three binding votes from the PMC (i.e. the > > >> > > >> majority of votes cast must be in favour and at least three PMC members > > >> > > >> must have voted in favour) > > >> > > >> > > >> > > >> Votes are a great way to *confirm* consensus, but a horrible way to > > >> > > >> build a > > >> > > >> community or establish consensus. We should only ever have a vote > > >> thread > > >> > > >> once the consensus seems to be established. > > >> > > >> > > >> > > >> To establish consensus we use a discuss thread. > > >> > > >> > > >> > > >> Please refrain from assigning blame, we want to grow our community not > > >> > > >> shrink it. The shorty endorphin rush you get from assigning blame or > > >> > > >> performing The Dance Of I Told You So™ will require repeated hits to > > >> > > >> maintain which will only lead to a more toxic community. > > >> > > >> > > >> > > >> We have not been good at maintaining our CI infrastructure: > > >> > > >> > > >> > > >> * As a consequence, some people have been developing on master rather > > >> > > >> than > > >> > > >> on branches in order to ensure that their development gets the benefit > > >> > > >> of > > >> > > >> the integration tests > > >> > > >> > > >> > > >> * This has lead to a lot of micro commits and effectively revert > > >> > > >> commits on > > >> > > >> master making it hard to track what actually has changed and what has > > >> > > >> actually been fixed. > > >> > > >> > > >> > > >> * Additionally `git blame` probably now could end up confusing people > > >> > > >> trying to understand the rationale for some changes > > >> > > >> > > >> > > >> We have not been good at maintaining our Integration tests: > > >> > > >> > > >> > > >> * As a consequence it has been hard to get our CI infrastructure > > >> working > > >> > > >> effectively > > >> > > >> > > >> > > >> * As a consequence, people have been forced to leverage a single branch > > >> > > >> for > > >> > > >> CI testing > > >> > > >> > > >> > > >> We have not been good at developing bigger changes in a branch > > >> > > >> > > >> > > >> etc. > > >> > > >> > > >> > > >> I could go on. > > >> > > >> > > >> > > >> My belief is that confidence in 3.4.0 has been eroded. > > >> > > >> > > >> > > >> I propose that we reset master back > > >> > > >> to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of > > >> > > >> master for the integration tests, and then immediately commit a dummy > > >> > > >> commit so that nobody accidentally does a fast-forward push. > > >> > > >> > > >> > > >> Then we can cherry pick the changes that were on the old master that we > > >> > > >> want to have in 3.4.0 > > >> > > >> > > >> > > >> This will probably also involve: > > >> > > >> > > >> > > >> * Fixing the CI infrastructure (I favour using a pipeline multibranch > > >> > > >> project so that branch development is easier, > > >> > > >> https://builds.apache.org/job/maven-jenkinsfile/ is where I have been > > >> > > >> trying to prototype this... currently failing because "windows") > > >> > > >> > > >> > > >> * Switching to a culture of branch / PR development for all committers > > >> > > >> > > >> > > >> * Better providing rationale for changes, e.g. we need a succinct > > >> > > >> description of the actual regression between 2.x and 3.x in resolution > > >> > > >> of > > >> > > >> dependencies of plugins as well as actual easy to understand tests that > > >> > > >> demonstrate the behaviour *and* show that it is an actual regression > > >> > > >> > > >> > > >> * etc > > >> > > >> > > >> > > >> But the first step in that would be to reset master... > > >> > > >> > > >> > > >> So... > > >> > > >> > > >> > > >> Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset > > >> > > >> to? > > >> > > >> > > >> > > >> What is the correct hash for the integration tests? > > >> > > >> > > >> > > >> Do we want to do this? > > >> > > >> > > >> > > >> What else should we change about our processes to prevent the need to > > >> do > > >> > > >> this again? > > >> > > >> > > >> > > >> Should we maybe just drop 3.4.x and jump to 3.5.x also in order to > > >> > > >> signal > > >> > > >> that this was a reboot version and any 3.4.x stuff is thus easy to > > >> > > >> detect > > >> > > >> and filter? > > >> > > >> > > >> > > >> Save your +1/-1's for actual vote threads, we need to establish a > > >> > > >> consensus > > >> > > >> first... then in a couple of days, if it looks like we have a consensus > > >> > > >> I > > >> > > >> will call a vote. > > >> > > >> > > >> > > >> -Stephen > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > -- > > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
