Closed jadrake75 closed 9 years ago
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 https://github.com/jadrake75/ng-scrolling-table/issues/79#issuecomment-68753874 .
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 https://github.com/jadrake75/ng-scrolling-table/issues/79#issuecomment-68772704 .
To move this along we need to push the dist folder of the "built" JS and CSS and also hook this up to bower