On Thu, Nov 9, 2017 at 1:04 AM, Ivan Kelly <iv...@apache.org> wrote:
> > 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.
>
I am not sure if this method is correct here. first, you are producing a
jar which has higher timestamp.
secondly, if you run maven install, I think there will be a local metadata
file for it.
>
> >> 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.
>
Are there use cases rather than CI workflow? In CI workflow, there are
already mature options for handling maven cache.
I am not sure this is a real big point on changing release flow.
>
> > 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.
Maven release plugin and Nexus are already there for simplifying things.
but you still need to run
it yourself. The ASF policy requires signatures on all the artifacts
published to artifactory.
Besides that, ASF artifactory doesn't allow a direct push. You have to
stage the artifacts into a
staging repo for reviews and release from the staging repo.
> 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
>
