Issue 6909046: Add the ability to make releases to the Makefile

Can't Edit
Can't Publish+Mail
Start Review

Created:
11 years, 4 months ago by benji

Modified:
11 years, 4 months ago

Reviewers:
mp+138740

Visibility:
Public.

Description

Add the ability to make releases to the Makefile The "dist" target creates a (gzipped) tar file which contains the entire branch sans the ".bzr" and "release" directories. This branch also introduces a CHANGES.yaml file. We are experementing with YAML (instead of text or reST) to see if it has any advantages, especially in the relm of displaying recent changes in the app itself. There are two kinds of releases that can be made and they can be made to either the "real" Launchpad site or to the staging site (for trial-runs). Full details have been added to the procedures documentation. https://code.launchpad.net/~benji/juju-gui/bug-1083618/+merge/138740 (do not edit description out of merge proposal)

	Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+318 lines, -2 lines)			Patch
M	.bzrignore	View		1 chunk	+2 lines, -0 lines	0 comments	Download
A	CHANGES.yaml	View	1	1 chunk	+26 lines, -0 lines	0 comments	Download
M	Makefile	View	1 2	3 chunks	+105 lines, -2 lines	0 comments	Download
M	README	View	1	2 chunks	+67 lines, -0 lines	0 comments	Download
A	[revision details]	View	1 2	1 chunk	+2 lines, -0 lines	0 comments	Download
M	docs/process.rst	View	1	3 chunks	+116 lines, -0 lines	0 comments	Download

Messages

Total messages: 6

Expand All Messages | Collapse All Messages

teknico

Lots of docs, I like it. Where are the Makefile tests? ;-) Ok, just joking. ...

11 years, 4 months ago (2012-12-07 15:45:19 UTC) #2

benji

Thanks for the review. I fixed everything. About tests: I got very close to writing ...

11 years, 4 months ago (2012-12-07 15:56:32 UTC) #3

benjamin.saller

This is heading the right direction, I'd be tempted to change more of it to ...

11 years, 4 months ago (2012-12-07 19:54:46 UTC) #4

benji

Thanks for the good review. I didn't quite understand a couple of your points, but ...

11 years, 4 months ago (2012-12-07 20:21:36 UTC) #5

Thanks for the good review.  I didn't quite understand a couple of your points,
but I think my replies may answer them anyway. ;)

https://codereview.appspot.com/6909046/diff/1/Makefile
File Makefile (right):

https://codereview.appspot.com/6909046/diff/1/Makefile#newcode31
Makefile:31: PENULTIMATE_VERSION=$(shell grep '^-' CHANGES.yaml | head -n 2 |
tail -n 1 \
On 2012/12/07 19:54:46, benjamin.saller wrote:
> Would it be better to use a small python (or external shell if you can find a
> cli yaml tool) program to read the YAML and take the last two entries in a
list
> of release entries? This seems fragile. 

I considered doing something like that but decided to call YAGNI on myself.  If
we decide we need to do it in the future it won't be too hard to do and the
failure modes are not too painful if I am wrong about not needing it.

> I understand this is just a few lines of shell, but its also the case that
> keeping as much procedural logic out of the makefile as possible is a good
idea.

We could make helpers in bin/ but that seems just slightly worse than having
them where they are.

> Still, if you feel strongly that it should be like this I'm ok with that. 

Lets try it like this and see if we want to put more work into it in the
future.

> Its also not entirely clear why we'd keep the changes as list with desc but
> without things like revno,

I don't follow.  Are you suggesting putting the trunk revision next to the
description of what changed?  That doesn't sound like a bad thing, but we
do not presently have a use case for it, and there is a bit of a race there.
(I can write the "next" revision in the CHANGE log, but someone may beat me to
it.)

> I also don't know if its work checking (maybe with
> bzrlib) that the release is tagged

We are not presently requiring that releases be tagged, that might be a
good idea.  If we do so, I suggest a follow-up card/branch.

> (and then we could use the tag in the changes
> file). If however there isn't a real 
> use for the changes (and w/o tags or revno I'm not sure there is) we could
> simply write revno to a file and use that value when building the release.

I'm afraid I don't follow this bit.

https://codereview.appspot.com/6909046/diff/1/README
File README (right):

https://codereview.appspot.com/6909046/diff/1/README#newcode139
README:139: 
On 2012/12/07 19:54:46, benjamin.saller wrote:
> Complicated set of flags, maybe these are different make targets? I see what
> your solving, but many of these are specialized for our team but will always
be
> used in certain ways I expect.

I don't think we will always be using a single combination of flags.  I
considered making them different targets, but the logic is such that very little
differs in the actual work.  A configuration-based approach seems to work best
for this.

If we do end up using one config or another exclusively we can refactor the
Makefile toward that end.

benji

11 years, 4 months ago (2012-12-10 14:39:14 UTC) #6

*** Submitted:

Add the ability to make releases to the Makefile

The "dist" target creates a (gzipped) tar file which contains the entire
branch sans the ".bzr" and "release" directories.

This branch also introduces a CHANGES.yaml file.  We are experementing with
YAML (instead of text or reST) to see if it has any advantages, especially in
the relm of displaying recent changes in the app itself.

There are two kinds of releases that can be made and they can be made to
either the "real" Launchpad site or to the staging site (for trial-runs).
Full details have been added to the procedures documentation.

R=teknico, benjamin.saller
CC=
https://codereview.appspot.com/6909046

Expand All Messages | Collapse All Messages