We need to publish the dist folder and add support for bower
Closed this issue · 6 comments
To move this along we need to push the dist folder of the "built" JS and CSS and also hook this up to bower
All I know about adding support for Bower is that every change requires a terminal branch of type X.Y.Z
Hopefully there is an easy way to merge change to new branches instead of doing it all by hand
did not know this. I didn't find much out there on how to go about doing this. Perhaps instead of merging to master, we only do so when we feel there is sufficient "functionality" or "features/defects" and instead work off a release branch (ie. it is the merge source). Then when things look "ready" they are merged, with an incremented version + distribution files and these are what get sent to bower?
Ok, looks like I was not entirely correct with my last statement. I may have been just looking at how Bower works and its expectations, one being that once something is submitted it cannot be changed and a new version number if required.
However after looking at: http://bob.yexley.net/creating-and-maintaining-your-own-bower-package/
It appears that the version picked up my Bower is both in the bower.json and a tag on the branch.
It also mentions grunt-bump that will increment these versions for you.
So maybe this is not as much of a pain to manage as I originally thought way back when I first investigated it.
Right, but we likely don't want to be bumping versions on every check-in
would we? Or ever issue resolved. I would think we'd want to do it in a
blob/group of issues and defects that make sense and can be thoroughly
tested together. Maybe I am wrong and bumping with each issue resolved
would be ok.
On Mon, Jan 5, 2015 at 1:40 PM, Xanir notifications@github.com wrote:
Ok, looks like I was not entirely correct with my last statement. I may
have been just looking at how Bower works and its expectations, one being
that once something is submitted it cannot be changed and a new version
number if required.
However after looking at:
http://bob.yexley.net/creating-and-maintaining-your-own-bower-package/
It appears that the version picked up my Bower is both in the bower.json
and a tag on the branch.
It also mentions grunt-bump that will increment these versions for you.So maybe this is not as much of a pain to manage as I originally thought
way back when I first investigated it.—
Reply to this email directly or view it on GitHub
#79 (comment)
.
I think either way would be fine but I don't think bumping every checkin would be needed. The grunt-bump is just an easy way to bump the version when needed. I'd say we would want to create a specific branch for every major and minor version and we would bump those version in Bower as needed.
Should we create a 0.1 branch and start from there or just keep things on master till we hit your 1.0 milestone?
grunt-bump looks kind of neat. There is also a built in release mechanism
in github. So I guess what I would propose is we check things in and then
use the github release to "publish" a new tag, or else how can we control
when a new version is created? Jenkins will just build when there is a
change, but not all changes should be releases (unless we use the stage
branch theory). ie. reserve master for bumped versions and check into a
staging branch.
On Mon, Jan 5, 2015 at 3:21 PM, Xanir notifications@github.com wrote:
I think either way would be fine but I don't think bumping every checkin
would be needed. The grunt-bump is just an easy way to bump the version
when needed. I'd say we would want to create a specific branch for every
major and minor version and we would bump those version in Bower as needed.
Should we create a 0.1 branch and start from there or just keep things on
master till we hit your 1.0 milestone?—
Reply to this email directly or view it on GitHub
#79 (comment)
.