> 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.
If it's a final version number, maven won't update.
Try this with bk master:
cd ~/.m2/repository/com/google/guava/guava/20.0
rm guava-20.0.jar guava-20.0.jar.sha1
touch guava-20.0.jar
sha1sum guava-20.0.jar | awk '{print $1}' > guava-20.0.jar.sha1
Now try to build. Even though guava 20 jar doesn't match what is in
remote repos, it won't be updated. The same will happen if there is an
RC with the same filename as the final release.
>> 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?
Maybe, maybe not. Really we want our end users to test release
candidates against their systems, but due to time constraints they may
not. Or if they're using this CI workflow (I've used this before to
test a ZK rc), it's quite possible the tests will run on a different
slave, so it'll use a different cache. It's also quite possible that
they will use the same slaves for the builds that generate their own
release builds, so a bookkeeper RC could make it into the released
product of one of our users.
> 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.
We don't have to change it now for 4.5.1 or 4.6.0. I'm suggesting we
think about changing it in the future because it can lead to issues.
Any time you've solved a problem by deleting your .m2 cache, it's this
issue.
I will see if I can find another ASF project that does this.
> 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.
This is another thing I meant to bring up. This last step should
pretty much be automated. Generating an RC should be automated. The
only thing a release manager should have to do is create a branch and
update versions in the pom, and this should be covered almost entirely
by the maven release plugin.
With RC artifact generation and final artifact generation automated,
this last review becomes useless.
>> 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?
maven.apache.org seems down right now :/. I'll check later.
-Ivan
