> Based on the feedback [1][2], I think the unexpected deployment is not > complete. > The dubbo-parent is not deployed the maven central. > Since all the sub modules depends on it, I think the compilation will > eventually fail. > Therefore I guess it is safe to use 2.6.3?
Yes, I think it’s say to go with 2.6.3. I have also tested on a separate machine, and no artifact of 2.6.3 can be resolved, ending with same exception reported by the user: failed to resolve dubbo-parent-2.6.3. Best regards, Jun > On 28 Aug 2018, at 22:21, Huxing Zhang <[email protected]> wrote: > > On Tue, Aug 28, 2018 at 10:06 PM Mark Thomas <[email protected] > <mailto:[email protected]>> wrote: >> >> On 28/08/18 05:56, Huxing Zhang wrote: >>> On Mon, Aug 27, 2018 at 10:44 AM jun liu <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> The sonatype team have deleted all artifacts of 2.6.3 from central >>>> repository. I will start 2.6.3 RC4 vote now. >> >> Just a thought. >> >> Some users may have downloaded 2.6.3 while it was on Maven central. If >> you now release 2.6.3 you could end up in the position where if a user >> reports they are using 2.6.3 you don't know which of the two 2.6.3 >> versions they are using. > > Based on the feedback [1][2], I think the unexpected deployment is not > complete. > The dubbo-parent is not deployed the maven central. > Since all the sub modules depends on it, I think the compilation will > eventually fail. > Therefore I guess it is safe to use 2.6.3? > > [1] https://github.com/apache/incubator-dubbo/issues/2331 > <https://github.com/apache/incubator-dubbo/issues/2331> > [2] https://github.com/apache/incubator-dubbo/issues/2326 > <https://github.com/apache/incubator-dubbo/issues/2326> > >> >> If the diff between the accidentally released RC and what ends up being >> formally released as 2.6.3 has zero functional impact then you are >> probably OK but there always the risk that there will be something. >> >> It is worth considering throwing away that version number and moving to >> 2.6.4 for the next release. >> >> More generally, version numbers are viewed as 'cheap' at the ASF. It >> isn't a big deal to decide not to use one for some reason. Tomcat, for >> example, doesn't use RCs. Most of our release votes pass first time but >> if they don't we fix the issue, increment the version number and try again. >> >> I have seen other projects decide not to use a version number of various >> reasons that all, generally, boil down to confusion over exactly what >> that version number represents. Moving to a new version number is often >> the simplest way to avoid potential confusion. >> >> Mark > > > > -- > Best Regards！ > Huxing
