Skip to content

Commit

Permalink
Fix instructions for creating releases
Browse files Browse the repository at this point in the history
  • Loading branch information
@hasufell
hasufell committed Mar 12, 2017
1 parent 3e9665d commit ef48dd0
Showing 1 changed file with 4 additions and 2 deletions.
6 changes: 4 additions & 2 deletions HACKING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -105,8 +105,10 @@ and give it to the [Translation Project](http://translationproject.org).
To make it available, you need to create a release and build an archive
from it.

git tag -a -m "Release 0.7.1" v0.7.1
git archive --format=tar.gz v0.7.1 pnmixer-0.7.1.tar.gz
export PN=pnmixer tag=v0.7.1
git tag -a -m "Release ${tag}" ${tag}
git archive --prefix=${PN}-${tag}/ --format=tar.gz -o ${PN}-${tag}.tar.gz ${tag}
unset PN tag

Then, on the github page of the project, create a new release, and attach
the archive. Copy the link of this archive, and send a mail to the TP with
Expand Down

12 comments on commit ef48dd0

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually there's no need to do that anymore, now that the potfile is versioned. When we release, we can just tag, and let GitHub automatically generate the associate tar and zip.

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you want to explicitely create the archive for a specific reason ?

@hasufell
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you want to explicitely create the archive for a specific reason ?

Yes, for persistence and security reasons (signing). Downloading git tags may or may not yield the same tarball. It is generated by the server, not a persistent file.

@elboulangero
Copy link
Collaborator

@elboulangero elboulangero commented on ef48dd0 Mar 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, I just re-wrote the translating instructions, see 297d0e5.

I now have a better understanding of the workflow with the TP, so I tried to explain it clearly. Explanations are a bit long, but the workflow is quite simple.

I kind of reverted your commit ef48dd0 (this one) in the process, no offense, it's just that creating an archive by hand is not needed anymore, at least for the translation part.

I should have re-wrote that weeks ago when I initiated the change to gettext, but I really didn't have time, sorry about that.

So if everything is good on your side, I just need to tag a new version (again !), then send that to the TP for translation.

Cheers

@hasufell
Copy link
Collaborator Author

@hasufell hasufell commented on ef48dd0 Mar 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I found the instructions useful and would like to keep them. We can move them to a separate place "creating releases" or something for our own personal reference and also add instructions about signing and so on.

I'll maybe do that later today, but yes, for the translation project we should be fine.

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep maybe we could rename that "Releasing", and separate into "Translation" and "Creating signed release (why and how)". I believe it should be separated though. For translation we need to provide a tarball, but preferably at rc stage, so that we have a chance to provide some updated translation in the final version. And I don't think we need a signed tarball for the rc (or do we ?), but only for the definitive version.

@hasufell
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just signed rc version for testing. Maybe I'll use/try the OpenBSD way of signing/verification: as in, signify-compatible.

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about a RELEASING.md file ?

@hasufell
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just use HACKING.md for all non-translation things. Translators are an exception so it makes sense to have a separate file there and not annoy them with unrelated info. For everything else I feel it's too fine-grained.

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you mean OK for a releasing file ? Because in the end the translation instructions are tied to releasing, since we don't really have to deal with translating the rest of the time. I think it makes sense to keep it together. It also makes sense to separate the release process from hacking. To me HACKING.md main's purpose is for coders who want to contribute, while README.md is for users. RELEASING.md is then only relevant for us maintainers.

@elboulangero
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could name it MAINTAINING.md...

@hasufell
Copy link
Collaborator Author

@hasufell hasufell commented on ef48dd0 Mar 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's not make a science out of it... just use something :D

Please sign in to comment.