New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Releaser needed for 2019.01 and following. #124

Open
stmuk opened this Issue Nov 11, 2018 · 13 comments

Comments

Projects
None yet
5 participants
@stmuk
Contributor

stmuk commented Nov 11, 2018

The release process is well documented and only takes a few hours every three months (or more frequently if you want).

Having access to OS X is needed for the DMG build and access to 64bit Windows (Virtual Box fine) for the MSI build.

@hankache

This comment has been minimized.

Contributor

hankache commented Nov 27, 2018

I volunteer.
What do I need in term of accesses?

@stmuk

This comment has been minimized.

Contributor

stmuk commented Nov 27, 2018

That's Great!

You need 1. commit access to this repo 2. to the perl6.org and rakudo.org website repos and 3. ssh access to servers.

There are some details in https://github.com/rakudo/star/blob/master/tools/star/release-guide.pod

@clarkema

This comment has been minimized.

Member

clarkema commented Nov 28, 2018

I'd be happy to help out with this as well, if you'd like to increase the bus factor!

@moritz

This comment has been minimized.

Member

moritz commented Nov 28, 2018

@hankache @clarkema I have invited you both to the perl6/perl6 and the rakudo/star teams on GitHub, which I believe gives you sufficient privileges on the GitHub side.

If you don't have SSH access for step 12 of the guide that stmuk linked to, please send me your SSH public key(s) to moritz.lenz@gmail.com, and I'll give you access.

If anything else is missing in terms of access, please don't hesitate to contact me, either in the #perl6 IRC channel, or via the email address mentioned above. I can't promise keys to every kingdom, but it's very likely that I at least know who to talk to :-)

Finally, since there are now two volunteers, who does the first release? First one to speak up wins :-)

@clarkema

This comment has been minimized.

Member

clarkema commented Nov 28, 2018

@moritz "wins"... ;) I'll have a go at it -- keys on the way.

@moritz

This comment has been minimized.

Member

moritz commented Nov 28, 2018

For the record, I've received two SSH public keys from @clarkema and have added them to the rakudo@rakudo.org user account.

@hankache

This comment has been minimized.

Contributor

hankache commented Nov 28, 2018

@moritz @clarkema no luck I was driving ;(

What about we do monthly releases? That way we can alternate each month and each one gets to do 6 releases per year?

@stmuk thank you for all the time you spent on rakudo/star

@moritz Will send you my keys in a bit, for the record I sent a CLA to the Perl foundation

@clarkema

This comment has been minimized.

Member

clarkema commented Nov 28, 2018

@hankache I guess we need to think about what kind of schedule would make sense for users and package builders. Looking at the Rakudo repo itself, it doesn't stick to an exact schedule of a release per month at the same point in the month. If we tried to do that with Star we risk running into situations when we're releasing Star with a version of Rakudo itself that only came out a few days previously.

I like the idea of making the latest goodies available for people who just want to brew install rakudo-star without having to do a full build themselves, but we also want people to feel comfortable relying on a Star release.

We could try a system along the lines of releasing every month with the previous month's Rakudo? So Rakudo 2019.01 becomes Star 2019.02, ensuring that things at least have a bit of time to settle before being fully released into the wild?

@AlexDaniel

This comment has been minimized.

Member

AlexDaniel commented Nov 28, 2018

FWIW I'm +1 for more than one person working on it. There's a lot of work to do, and IMO doing it alone is not the best idea.

@stmuk

This comment has been minimized.

Contributor

stmuk commented Nov 28, 2018

The schedule I more or less used for 3 years was to release every quarter (20XX.01, 04, 07, 10) a Release Candidate (RC) a weekend after the upstream release with the final release the following weekend. I would aim to hit the Monday's Perl 6 Weekly both times. This seemed to mostly work well and allowed enough time for upstream issues to be spotted in the monthly although I never really got much feedback about the star RC itself. Usually someone would point out a typo in the release accouncement after the release :)

Very occasionally I would put a patch in star to fix a problem with upstream but this hasn't happened for a while. Sometimes MoarVM or NQP had a dot release due to a problem. But not so much recently. Upstream is taking longer for its monthly releases (probably due to the number of changes going in and increased testing) and did skip one release this year due to problems. I think having similar but different release numbering for star and upstream would be too confusing.

@stmuk

This comment has been minimized.

Contributor

stmuk commented Nov 28, 2018

@clarkema @hankache If you are both releasing you might want to consider sharing a GPG key for the release. Although I just used my own and it would be easiest to continue with personal keys to prevent private key exchange issues. I could sign keys and I think Alex signed my key.

@clarkema

This comment has been minimized.

Member

clarkema commented Nov 28, 2018

If that process has worked well so far, then let's stick with it. @hankache you're welcome to take the first one though; or maybe we could work through it together.

@stmuk thanks for leaving it in such a good state -- the whole process seems well documented and easy to follow. I've just worked through it without committing anything, and it seemed fairly straightfowards, at least for the .tar.gz.

@stmuk

This comment has been minimized.

Contributor

stmuk commented Nov 28, 2018

@clarkema It was set up well from the start! Most things are fairly straightforward. Making a list of module changes is always a little fiddly as is building the Windows MSI and maybe sorting the module deps when they change but otherwise it's usually plain sailing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment