Comments (17)
yes, yes and yes. will be looking at integrating this. If we are going for this tho, we really need to pay attention to semver tho ;) /cc @janl @gr2m @caolan
from discussion.
like it.
from discussion.
Maybe use a grunt plugin? https://github.com/vojtajina/grunt-bump
from discussion.
@Acconut we use this in hoodie.js
not a fan of it, also completely detached from testing / integration tests.
from discussion.
Since there have been two issues with hoodie-cli which have been fixed in the repo but not been pushed to npm: Any progress on this?
from discussion.
This wouldn't have fixed the issue as we'd be relying on tags. Which, creating tags needs about the same amount of work as running npm publish
from discussion.
Ok, that's a good point.
from discussion.
Let's see how this pans out next time we add a tag.
from discussion.
Nice, π
from discussion.
Somewhat related. hoodiehq/hoodie-server#257
from discussion.
This issue is related to hoodiehq/hoodie-server#257, hoodiehq/hoodie#218 and vojtajina/grunt-bump#47 but it's hard to discuss one and the same thing in 3 different spots w/o confusion so I'll try to cover everything related to automated versioning & releases here.
There is consent that versions should be released in a consistent and automated way, so here is my suggested workflow.
grunt-bump
Let grunt-bump
take care of the version numbers and a tagged commit.
The concerns regarding grunt-bump
are no longer valid, as it is possible (now?) to manipulate and add files between the version bump and the commit. Demo from the docs:
$ grunt bump-only:minor
$ grunt changelog
$ grunt bump-commit
creating tags needs about the same amount of work as running npm publish
I disagree here, because grunt bump also takes care of bower.json or source files. Also it offers an abstraction layer for version numbers with the :major
, :minor
and :patch
flags, so there is even less thinking (read inconsistencies) involved.
I'd configure grunt-bump to automatically push to origin, so there is no way to forget the --tags
flag, while doing it yourself.
TravisCI npm deploy
364164f0e7e2aeee177d0064b0ed1e2514ae7eaf is already perfect. What I like about the Travis deploy hook, is that there is no way to accidentally publish a failing build.
Changelog
In my opinion a changelog should come with every release. The easiest way is to generate it from the commit messages, but that requires commit message conventions. I know there are already some in place, but the excellent tools the angular team provides are worth the switch.
type(scope): message
e.g.
feat(payments): add stripe
To v
or not to v
Tags aren't necessarily version numbers, so the added unambiguity of a v
prefix is a good thing. Can you please elaborate why you'd ditch them?
If there's consent about these things I can take care of implementing them across repos, but first some more discussion \o/
from discussion.
@boennemann thanks for taking the time and putting it all together! Regarding To v
or not to v
β I don't care what we do, as long as it's consistent. I have a preference like all of us, but if you're willing to take the responsibility to setup all the things (grunt task, changelog, docs), just go ahead and choose whatever you like, or what is mostly used right now in the repositories.
Thoughts? @caolan @janl @zoepage @svnlto
from discussion.
thanks for taking the time and putting it all together!
Just as an FYI:
npm version {major|minor|patch}
adds the v
prefix by default..
from discussion.
+1
On 13.05.2014, at 00:42, Stephan BΓΆnnemann [email protected] wrote:
This issue is related to hoodiehq/hoodie-server#257, hoodiehq/hoodie#218 and vojtajina/grunt-bump#47 but it's hard to discuss one and the same thing in 3 different spots w/o confusion so I'll try to cover everything related to automated versioning & releases here.
There is consent that versions should be released in a consistent and automated way, so here is my suggested workflow.
grunt-bump
Let grunt-bump take care of the version numbers and a tagged commit.
The concerns regarding grunt-bump are no longer valid, as it is possible (now?) to manipulate and add files between the version bump and the commit. Demo from the docs:
$ grunt bump-only:minor
$ grunt changelog
$ grunt bump-commit
creating tags needs about the same amount of work as running npm publishI disagree here, because grunt bump also takes care of bower.json or source files. Also it offers an abstraction layer for version numbers with the :major, :minor and :patch flags, so there is even less thinking (read inconsistencies) involved.
I'd configure grunt-bump to automatically push to origin, so there is no way to forget the --tags flag, while doing it yourself.
TravisCI npm deploy
364164f is already perfect. What I like about the Travis deploy hook, is that there is no way to accidentally publish a failing build.
Changelog
In my opinion a changelog should come with every release. The easiest way is to generate it from the commit messages, but that requires commit message conventions. I know there are already some in place, but the excellent tools the angular team provides are worth the switch.
type(scope): message
e.g.
feat(payments): add stripeconventions doc
pre-commit validation
changelog generator
To v or not to vTags aren't necessarily version numbers, so the added unambiguity of a v prefix is a good thing. Can you please elaborate why you'd ditch them?
If there's consent about these things I can take care of implementing them across repos, but first some more discussion \o/
β
Reply to this email directly or view it on GitHub.
from discussion.
+1
thank you @boennemann for doing this! <3
from discussion.
So I'll just interpret this as a "go for it".
I will start w/ hoodie-cli so we can discuss details and then apply it to the rest of the repos.
Fun fact: There is a defined process already: https://github.com/hoodiehq/hoodie.js/blob/master/CONTRIBUTING.md#releasing-a-new-version
from discussion.
Excellent! Thanks Stephan!
from discussion.
Related Issues (20)
- Changelog? HOT 2
- Server API for databases and data HOT 16
- [maintainers RFC] replace lgtm.co integration with requiring reviews HOT 5
- tasks: provide user context
- all users have access to all data and a central db HOT 1
- [RFC] merge UI from @hoodie/store & @hoodie/account into hoodie HOT 4
- Store: Hoodie properties added to documents HOT 19
- scoped stores and the type property HOT 21
- Move configuration from ./package.json to ./hoodie/config.js HOT 7
- admin accounts and server secret HOT 3
- ππ Letβs use readthedocs.org for Hoodie HOT 4
- Implementation of Web App with Data Sharing Requirement HOT 4
- Rails Girls Summer of Code 2017 submission ππ©π»βπ»π©πΎβπ»β¨ HOT 4
- Google Summer of Code submission HOT 2
- Change our Code of Conduct HOT 6
- (client) remove hoodie.ready.then(...) HOT 2
- Overlap with SuperLogin HOT 1
- Hook or event when local database is created HOT 7
- @hoodie/api HOT 6
- Would love to be part of the organization and contribute towards it. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from discussion.