search

apigee-127 / sway

A library that simplifies OpenAPI (fka Swagger) integrations/tooling.
MIT License
190 stars 92 forks source link

why is the package.json still 1.0.0 when you have dependencies and code changes? #176

Closed saywow closed 6 years ago

saywow commented 6 years ago

Can you please bump up the versions in your package.json to reflect the recent changes? Much appreciated, this will help us as consumers of your package to track changes and version control.

whitlockjc commented 6 years ago

I could bump it to 2.0.0 since that is likely the next version to be released. It might have an impact on tooling but I can figure it out.

ehmicky commented 6 years ago

I was going to post the same issue. One of the upsides of doing it is that at the moment npm audit reports a production vulnerability linked to json-schema-faker. Since the the latest commit have upgraded that library, this fixed the problem. I.e. releasing a new version would allow using this library without npm audit vulnerabilities.

whitlockjc commented 6 years ago

Since I've never followed this approach before, bumping master before you know which version it will apply to, what is the suggested approach? Is there some npm/semver/package.json documentation somewhere saying how we should do this?

ehmicky commented 6 years ago

I am trying to understand what the problem is: can't you bump the version in package.json then publish to npm?

whitlockjc commented 6 years ago

I'm not saying there is a problem, I'm asking for details on the convention.

ehmicky commented 6 years ago

I am sorry, I think there must be something I do not understand. The convention seems to be to bump the version in package.json, update changelogs, use git tag then run npm publish but you definitely already know this, so I think I might not understand your initial problem.

whitlockjc commented 6 years ago

I'm just talking about the convention of updating package.json in master after a release. What should the version be?

ehmicky commented 6 years ago

It seems to me (correct me if I'm wrong) that following semver, and going through the new commits (which do not seem to introduce breaking changes but do introduce new features), it should be 1.1.0.

penx commented 6 years ago

from my understanding, @whitlockjc is preparing for a v2 release but is not happy that the current code base is stable enough to push something out now. He also thinks the current code base may have drifted too much from v1 that the next update should be a major update.

If the above is correct, I'd recommend releasing the current code base as v2 prerelease (e.g. 2.0.0-alpha.1) https://semver.org

I think regular releases would benefit most users, and if @whitlockjc isn't happy they're stable then doing them as prereleases should hopefully keep everyone happy :-)

fed135 commented 6 years ago

Hum: https://github.com/apigee-127/sway/issues/157 It's my humble opinion that all changes to master should result in a version change and a publish.

A good way of implementing this would be:

That way, all the users can choose how they receive package updates.

whitlockjc commented 6 years ago

@fed135 I like the idea. Let's say we're in the spot we are now (nearing v2.0.0 release, master hasn't been managed the way you're suggesting, etc.), how do we get there ASAP? I'm cool with the whole "all changes go through PRs" bit (although I'm not sure I want to wait to get PRs approved for my own changes), all master changes become some new automatically-versioned, pre-release version that is published. But...how? Want to help?

fed135 commented 6 years ago

I've just now implement full CI on my new OSS, I can definitly help :)

whitlockjc commented 6 years ago

I'm already using Travis to do CI but we're not doing CD on master and I think that's a cool idea.

fed135 commented 6 years ago

177

chadxz commented 6 years ago

seems to me that updating package.json as part of a pull request would be rather tedious. What happens when there are multiple pull requests open at the same time? How do you manage who sets their version to what?

Seems like there's a step missing here.

fed135 commented 6 years ago

It is indeed, it's a shortcut that only projects with one or two maintainers can take.

If you're up for it, you could add a next branch to your repo, lock it and mark it as default. PRs will all go to this branch, and when you feel comfortable bumping the package version, you just create a PR from next to master.

This approach is closer to the classic git workflow: https://nvie.com/posts/a-successful-git-branching-model/

whitlockjc commented 6 years ago

package.json is now at 2.0.0. I'm going to close this for now but I do hope the discussion continues. Once we have an agreed-upon plan, we'll create an appropriately described/named issue to do the work.