On Wed, Nov 8, 2017 at 1:02 PM, Ivan Kelly <iv...@apache.org> wrote: > > I am not sure why this will screw up the caches. if a RC is approved as > the > > final, then there is no sha change and it is final. > > Your local installation from a RC repo should be exactly same as the one > > available in the central. If a RC is not approved, > > then it means changes will come in next RC, if you already cache the > > previous RC locally, when a new RC is up, the gitsha > > is changed, maven will update your local cache. > Does maven check the gitsha when deciding whether to pull a version? > My understanding is that, if the version in the dependency is a > non-snapshot version, and it finds an artifact with that version, it > will just use that version. >
it doesn't have the notion of gitsha. but it has the timestamp (I also have limited knowledge on this. I can be wrong) and a policy to check for updates. If a RC is bad, a new RC will be produced with new timestamp. Maven should be able to resolve and find there is an update for it. e.g. https://repository.apache.org/content/repositories/orgapachebookkeeper-1015/org/apache/bookkeeper/bookkeeper-server/maven-metadata.xml > > Now, consider the case where one of our users wants to test a new > version of BK works well with the system they have built on top of it, > so they change the version in the file, add the temp repo to the > repos, commit and kick off their CI to run unit, integration, scale > tests etc. If their build system isn't purging the environment every > time, they will end up with a RC artifact as the final artifact for > that version, which is bad. > If the RC is bad, a new RC will come out to fix the bad RC. They will run the procedure to verify new RC, no? I don't really see how bad is the current process. Instead, changing it to use "-rc" suffix for publishing artifacts, changes the whole release process that every other projects are using. It also sounds we are bypassing the staging repository feature provided by Nexus and reinvent a new process for publishing artifacts. I am not sure it really worth doing this change. Personally I would like to see if there is a project doing this process before changing it. > > > The point is if you produce artifacts locally using a RC should be > exactly > > same as it is final in public. Otherwise, there is no > > point for review. Because the process of converting a RC to final will > > never be reviewed. > Converting the RC to final will produce a new gitsha, yes. But are we > actually checking that the gitsha matches the version in maven and the > tarballs generated. I, at least, generally trust that the release > manager generated the artifacts from the tag they claimed. > we don't have the mechanisms to do this gitsha and package matching. we trust release manager. BUT at least, what release manager claimed (tag, binary/source distribution, maven artifacts) are all reviewed and approved. if you do additional RC to final convert, it means new checkin, new tag, new binary/source package, and new artifacts. no one really review and verify all these stuff again. > > > "an rc tag"? Do you mean a git tag name with "-rc" suffix? or do you mean > > the staging artifacts version with "-rc" suffix? > I mean an -rc suffix on the version. > > > I have seen projects using "-rc" suffix for tag name. but I don't see > > projects using "-rc" suffix in the artifact version. > > > > Can you point me an ASF project that is doing in this way? If it works > well > > in other projects, we can learn from them. > Maven itself. > http://maven.apache.org/developers/release/maven-core-release.html (maybe I missed something here) I checked the maven release process. the versioning is about the binary/source distribution, which we are doing the same thing, no? I don't see what is the process of publishing artifacts (does maven publish artifacts?). the proposal of using "-rc" is actually breaking the process of having a staging repo in nexus. Can you point me the section how maven does that? > > > -Ivan >
