Clarify release process

[no-reply]

The release process contains information about a deprecation script which outputs commits that include deprecations. It doesn't say what you should do with that information.

It would be useful to add some clarity about what should go in release notes, too.

[mjgiarlo]

Perhaps related, perhaps not: it might be nice to unify our release procedure across Hydra projects, and consolidate that documentation under the Hydra repo, perhaps in a file called RELEASING.md or some such. The most complete version of the release procedure that I know of lives here:

https://github.com/projecthydra/active_fedora/wiki/Release-management-process#activefedora-release-management-step-by-step

And it could benefit from some review for accuracy and completeness.

[jeremyf]

Perhaps a "README" directory? To have CONTRIBUTING, TESTING, RELEASING, USAGE, etc. All angry!

On Fri, Apr 25, 2014 at 2:27 PM, Michael J. Giarlo <notifications@github.com

wrote:

Perhaps related, perhaps not: it might be nice to unify our release procedure across Hydra projects, and consolidate that documentation under the Hydra repo, perhaps in a file called RELEASING.md or some such. The most complete version of the release procedure that I know of lives here:

https://github.com/projecthydra/active_fedora/wiki/Release-management-process#activefedora-release-management-step-by-step

And it could benefit from some review for accuracy and completeness.

— Reply to this email directly or view it on GitHubhttps://github.com/projecthydra/hydra/issues/54#issuecomment-41441283 .

Jeremy Friesen takeonrules.com

[mjgiarlo]

If these files are in a directory, would GitHub be smart enough to do the magic thing it does when you put files like README and CONTRIBUTING in the root? If so, cool. If not, I'm OK with the root being a bit document-y. No matter where we put it, I am in favor of:

1. Basing the RELEASING documentation on the above document, which covers parts of the release process that others do not; and
2. Unifying our release process across all Hydra gems so RELEASING works across the board. We're probably most of the way there already. (Do all gems use rake release? Do some use rake all:release instead? Is this a meaningful distinction worth perpetuating? etc.)

:bow:

[mjgiarlo]

(:point_up: is also inspired by a conversation I had with @jpstroop a few weeks ago about pushing a release of http://github.com/projecthydra/hydra-derivatives .)

[jpstroop]

Argh, yeah, I meant to bring this up this week and completely forgot. Thanks for surfacing it!

[mark-dce]

I'm thinking that putting the release process in individual github repos is a great way to get it to drift across repos: https://github.com/projecthydra/hydra/blob/master/RELEASE-POLICY.md vs. https://github.com/projecthydra/active_fedora/wiki/Release-management-process vs. https://github.com/projecthydra/hydra-head/blob/master/RELEASING_HYDRA_HEAD.rdoc vs. https://github.com/projecthydra/sufia/wiki/Release-management-process [matches AF] vs. [deprecated, but seemingly more complete] https://wiki.duraspace.org/display/hydra/Release+Manager+Responsibilities

Thoughts?

[jpstroop]

FWIW, as a noob to the process, I found https://github.com/projecthydra/active_fedora/wiki/Release-management-process to be most useful.

The other question I had that doesn't seem to be covered anywhere (unless it is...I wasn't aware of all of the links above) was the appropriate method for bumping the version of a gem--specifically, whether it was OK in this instance to push directly to upstream/master. In hindsight it seems like a silly question, but when nervously pushing to a big shared repo for the first time, one questions everything :smile: .

I do think pushing a doc to each individual repo would be ideal. I'm not sure I'm qualified to draft such a doc, but (again, as someone new to the process) I would be more than happy to review it.