Better release strategy (with bower)

[parasyte]

@agmcleod @obiot I have been investigating bower more closely, which was discussed a bit in #227.

My understanding of the bower package manager ecosystem is still vague, at best. But it does appear to be useful for the distribution of pre-built melonJS releases -- something we are NOT doing with it yet.

In my experiments, I installed jQuery using bower install jquery in an empty directory. It creates a subdirectory called bower_components (synonymous to node_modules with npm) and jQuery is installed there. What's interesting to note is that in the jquery subdirectory, there's the full source code, plus the pre-built js files in a dist directory. And the bower manifest points to one of these dist files: https://github.com/jquery/jquery/blob/master/bower.json#L4

But if you look at the jQuery repo, you'll see that there is no dist directory, and in fact, it is ignored in .gitignore! But if you check out their latest tag, you will indeed find the dist directory: https://github.com/jquery/jquery/tree/2.1.1/dist This means the 2.1.1 tag is not in any branch. So jQuery's dist/bower register step must detach the branch, commit the dist files, tag the commit, and push the detached tag.

This is the flow I tested in a new repo, and it works really well: https://github.com/parasyte/hork The build directory is purposefully empty (just a placeholder) And I have made three tags, each with a different build file that never touched a branch, with all tags having histories from different points in the master branch. Here's how we might do this with melonJS:

grunt
git checkout --detach
git add -f build/melonjs-1.0.1-min.js
git add -f build/melonjs-1.0.1.js
git commit -m "Release 1.0.1"
git tag 1.0.1
git push origin 1.0.1

What we're doing here is building the dist files with grunt, then detaching from the branch and committing the dist files in the detached state. This creates the commit sha1 in git history, but the commit isn't really linked anywhere. To link it with something, a tag is created (which integrates with the github release mechanism) and the tag is pushed to remote (github) to create the release.

And of course, all of these steps can be automated to pull the version number from package.json.

With all of that done, we should be able to bower install melonJS and get the dist files (plus source code) installed into our project when starting a new game. No need to build melonJS, no need to install any build dependencies, and finally the npm install task does not need to run bower; they can live entirely independent of one another, the way it should be.

---

Final note: This takes us back to our current release strategy of just using tags to keep track of releases. That much won't change. But what will need to change is how the "Stable" branch is initially created. I'll use "1.1.0" as an example for when we start to work on "1.2.0":

1. master is the current "1.1.0" development line. We want to start working on "1.2.0".
2. Create a new branch from master named 1.1.x.
   1. Create a new detached tag (see above) named 1.1.0 containing dist files.
   2. Continue work in the 1.1.x branch, with periodic detached tags for releases.
   3. Never commit on top of a tag.
3. Update all version numbers in master to "1.2.0".
4. Continue work in the master branch for unstable/experimental features in the 1.2.x line.

[parasyte]

I was able to write a shell script for this, but for portability we should probably continue using node. gift might be enough to run the git commands needed. Then it can just be a new grunt release task.

[ellisonleao]

doing a little research, found those projects that could be useful:

https://github.com/geddski/grunt-release

http://rafeca.com/node-releasetools/Jakefile.html (Nice project name BTW)

[parasyte]

grunt-release is almost exactly what I want for this. I say "almost" because it doesn't do the detach step. It's a trivial change, but still needs a fork.

[ellisonleao]

back to this, so can we create our version of bower-release? Or just a simple node/bash script to do this trick. I think we can go simple on the start.

[parasyte]

For sure it's simple. The bash script is above. This is really just a task that needs to be done. The design is complete.

[ellisonleao]

sure, just to clear things out. Should we create a custom task on the tasks folder and add this bash script to be executed, or should we try to use pure node.js libs to reproduce that script? I think i can do that modifications.

[parasyte]

I would prefer to do it with node, for portability reasons (especially building on Windows). That's the reason I didn't commit a bash script. But you can still use the script as a guide. Here's the one I was testing a few weeks ago: https://github.com/parasyte/hork/blob/master/tasks/release.sh

I think you might be able to write the task using gift to execute the git commands, but it will require some experimentation.

[ellisonleao]

sure, i will take a closer look.

[obiot]

is this something that can be done within the next couple of days, or is it better to plan this for 1.0.3 or the 1.1.0 branch ? (i'm ok with both)

[ellisonleao]

I think we can do this for 1.1.0 (master) . I've already started to work on the release task, you can check it here: https://github.com/ellisonleao/melonJS/commit/8b7d618a3aea8e72f3349ac222acc7fa0c2284ca

[obiot]

works for me, and the sooner we get this 1.0.2 out, the sooner i can go back focusing on 1.1.0 as well and the new object/collision stuff ;P

[ellisonleao]

hey guys, some news on this one.
I've tried to use the gift package, but i had no success due to the lack of options on the git commands, so i took a look at the grunt-release project and read the task code to see how they handle the git commands. I had some success by using the q and shelljs packages. You guys can check the code here https://github.com/ellisonleao/melonJS/blob/master/tasks/release.js

The only problem now is that the commit function is not being executed, and i still can't figure out why. Any thoughts?

[parasyte]

@ellisonleao This sounds pretty cool, and the code is clean and simple. I read through it on the plane, and liked what I saw. Unfortunate that it wasn't working as you intended, though. I haven't tried it beyond that yet.

[obiot]

what about this one btw ? do we try to finalise it before the final 1.1.0 release ?

[parasyte]

I would love to use this to release 1.1.0. ;) I'm going over the pull request (#528) now.

[obiot]

i'm postponing this one to 1.2.0 then (or maybe 1.1.1 a bit later)

[ellisonleao]

sounds good! I will try another approach this week. Let's hope for the best.

[obiot]

ooooh yes, I almost forgot about this one :):):)

[ellisonleao]

sorry about the late on this one. I had a really busy time these past two months since i am getting married on November. I will try to finish ASAP

[agmcleod]

congrats :)

On Thu, Oct 9, 2014 at 9:20 AM, Ellison Leão [email protected]
wrote:

sorry about the late on this one. I had a really busy time these past two
months since i am getting married on November. I will try to finish ASAP

—
Reply to this email directly or view it on GitHub
#508 (comment).

Aaron McLeod
http://agmprojects.com

[obiot]

Congratulations !!!!!!!!

And please no worries about the ticket :)

On 09 Oct 2014, at 21:38, Aaron McLeod [email protected] wrote:

congrats :)

On Thu, Oct 9, 2014 at 9:20 AM, Ellison Leão [email protected]
wrote:

sorry about the late on this one. I had a really busy time these past two
months since i am getting married on November. I will try to finish ASAP

—
Reply to this email directly or view it on GitHub
#508 (comment).

Aaron McLeod
http://agmprojects.com
—
Reply to this email directly or view it on GitHub.

[parasyte]

There are two alternatives for the git commands, both use libgit:

• https://github.com/nodegit/nodegit (under very active development)
• https://github.com/libgit2/node-gitteh (last updated in September)

These provide low-level access to a git repo. I would be surprised if all the tasks cannot be done with this. Also we won't have to rely on the broken behavior in shelljs as we see in #508

[luiscoms]

Add dependency of MelonJS isn't working yet?

[parasyte]

This one is fixed. I had a lot of trouble with the last little stretch, but it's now working with rollback on failure cases!

The new release command is:

$ grunt release

Requires npm update to install new dependencies. The first release to use this will be v2.2.0.

[obiot]

Ooohh nice !

So basically "grunt release" will do the whole release stuff ?

On 3 juin 2015, at 16:13, Jay Oster [email protected] wrote:

This one is fixed. I had a lot of trouble with the last little stretch, but it's now working with rollback on failure cases!

The new release command is:

$ grunt release
Requires npm update to install new dependencies. The first release to use this will be v2.2.0.

—
Reply to this email directly or view it on GitHub.

[parasyte]

Yep, it does! There's a followup ticket for a few minor things left to do.