Opened 4 years ago

Last modified 23 months ago

#18732 assigned task

Document release process for Java projects

Reported by: iwakeh Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics Version:
Severity: Normal Keywords: metrics-2018
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Release Process description should be based on existing documentation:

metrics-lib's CONTRIB.md

and after completion be referenced by metrics-lib's README

Child Tickets

Change History (13)

comment:1 in reply to:  description Changed 4 years ago by iwakeh

...
and after completion be referenced by metrics-lib's README

this ought to be metrics-db

comment:2 Changed 4 years ago by iwakeh

Owner: set to iwakeh
Status: newaccepted

comment:3 Changed 4 years ago by iwakeh

Always add a javadoc jar to a new release (see #18792 comments 3 and 4).

comment:4 Changed 3 years ago by iwakeh

Component: Metrics/CollecTorMetrics

comment:5 Changed 2 years ago by karsten

Summary: describe release process for java projectsDocument release process for Java projects

Tweak summary.

comment:6 Changed 2 years ago by karsten

Keywords: metrics-2018 added

comment:7 Changed 2 years ago by karsten

Keywords: metrics-2017 added; metrics-2018 removed

comment:8 Changed 2 years ago by iwakeh

Keywords: metrics-2018 added; ctip metrics-2017 removed
Parent ID: #18730

Removed parent ticket and set to metrics-2018.

We do have a well working release process by now, not only for metrics-lib.
There should be a section or page added to the wiki explaining the step.

How detailed should it be:
Just the process as viewed from the outside?
A general description of steps?
Or a very detailed list of the various steps for generating the release and testing and announcing it?

comment:9 Changed 2 years ago by iwakeh

Status: acceptedneeds_information

comment:10 Changed 2 years ago by karsten

Huh, fine question about the detail. I could imagine that the main audience of this documentation would be fellow team members who happen to work on putting out releases now or in the future. How about we switch roles for putting out a future release, where you prepare the pre-release tarball, I test it, you sign and upload, and I announce it? Maybe we'll have to do it after the Rome meeting after more people had the chance to sign your PGP key. We would both write documentation for our current roles in this process and then try out and improve the documentation of the other when taking over their roles.

comment:11 Changed 2 years ago by iwakeh

Ok, with that audience in mind (and no description for the general public etc.) it can be quite short, a few lists of steps.

Actually, for my part except for the announcement (although, that could also be automated using natural language generation ;-) didn't get around to it yet) I have a script by now that checks everything.
The deliverable of this ticket could consist of a list of release steps or a flow chart (prepare and test pre-release, prepare and sign and test release, announce) and scripts for almost all steps in there?
Do you also have scripts? Which git repo could be used/created?

And, of course, a very good verification of the result would be switching roles as you suggested.

comment:12 Changed 2 years ago by iwakeh

Status: needs_informationaccepted

comment:13 Changed 23 months ago by iwakeh

Owner: changed from iwakeh to metrics-team
Status: acceptedassigned

Move to metrics-team as these are not worked on by me during the next week.

Note: See TracTickets for help on using tickets.