ga4gh / ga4gh-schemas

Models and APIs for Genomic data. RETIRED 2018-01-24
http://ga4gh.org
Apache License 2.0
214 stars 114 forks source link

278 maven repository #762

Closed ejacox closed 7 years ago

ejacox commented 7 years ago

Updated maven repository release notes. Close #278

heuermh commented 7 years ago

Sorry, I don't follow what is happening here, nor the motivation. Can someone explain? The version set in pom.xml (0.6.0a) does not match that used elsewhere (0.6.0-a9).

fnothaft commented 7 years ago

+1 @heuermh's comments. Manually modifying the POM and then deploying is not best practice, and is a step backwards relative to the previous release scripts.

ejacox commented 7 years ago

What is wrong with modifying the POM?

The previous release script didn't work. How is this a step backwards?

heuermh commented 7 years ago

What is wrong with modifying the POM?

The only time the version in pom.xml should be the same as a release version is on a commit with a release tag or on a release branch. Otherwise anyone building locally or depending on git HEAD (which if I understand correctly is how ga4gh server works, i.e. https://github.com/ga4gh/server/blob/master/constraints.txt#L27) can build artifacts with the same version as a release but different code. Those artifacts would fail checksums and signature validation and could break downstream code.

The Maven build ecosystem (e.g. Maven, Ivy, Gradle, SBT, etc.) uses -SNAPSHOT version numbers to indicate work-in-progress towards the next release version number. Git HEAD should always be set to a -SNAPSHOT version number.

The previous release script didn't work. How is this a step backwards?

I've been volunteering to help with this since Apr 2015 if not earlier, with repeated offers to help since then. "didn't work" how? I can be available via irc or gitter or slack or on the phone or whatever it takes.

fnothaft commented 7 years ago

+1 @heuermh; as stated many times before, I'm also glad to hop on the phone/etc to sort this out. The prior scripts are derived from the release scripts we have used to cut ~10 releases in the past year across 4 different projects. As such, I can say with full confidence that any bugs that were in the script are minor mistakes that were introduced when migrating the scripts to a new repository.

fnothaft commented 7 years ago

Apologies for being a pain, but we've been blocked wrt supporting the GA4GH schemas for more than 6mo due to the lack of proper release artifacts (we've had to cut our own forked release to support 0.5.1, even) and we have repeatedly offered support (the original scripts and docs, hopping on calls, email threads, etc) with the release workflow. Can we properly resolve this release workflow issue so that we can move on with downstream development? Perhaps it'd be most productive to get on a call to circle up?

kozbo commented 7 years ago

Thanks @heuermh and @fnothaft for all the help and comments, and you are not "a pain" :-). We now have someone to chase this one down (@ejacox) so progress will be made. Looks like the first approach isn't quite right so yes, let's set up a call this week. Let me check in with Edwin tomorrow and then suggest some times.

fnothaft commented 7 years ago

Thanks @kozbo and @ejacox, I look forward to working together to sort this out.