Comments (23)
Semver level is the most important detail of a commit, because it dictates the versions allowed to include it. That's why I want it in the subject. If we're worried about space, I'd advocate moving component(s) into the body first, since they take up even more (especially if a commit affects multiple) and seem most useful for changelog generation, which requires the full body anyway.
Regardless, though, git log [--grep]
can support any rational scheme. The point is to start capturing this information, and I'd prefer to do so consistently (hence the issue).
from contribute.jquery.org.
Since you mention cherry-picking, maybe this is very specific to Core, with two stable releases managed in the same repository?
This has nothing to do with us having two parallel branches. This is a result of us wanting to not release jQuery Compat at all and instead release 1.12 & 2.2 that will have non-breaking changes backported from compat
& master
respectively (and stop cherry-picking to compat
afterwards). We need to identify commits that introduced breaking changes so that we don't backport them.
from contribute.jquery.org.
Node.js has been using more the verbose (SEMVER-MINOR)
and (SEMVER-MAJOR)
in their commit messages.
For example: https://github.com/nodejs/node/blob/v5.0.0/CHANGELOG.md#commits
Commits
- [
1a41feb559
] - buffer: don't CHECK on zero-sized realloc (Ben Noordhuis) #3499- [
5f6579d366
] - (SEMVER-MAJOR) buffer: remove raw & raws encoding (Sakthipriyan Vairamani) #2859- [
870108aaa8
] - (SEMVER-MAJOR) console: sub-millisecond accuracy for console.time (Michaël Zasso) #3166- [
680dda8023
] - dns: remove nonexistant exports.ADNAME (Roman Reiss) #3051
from contribute.jquery.org.
I don't really want to implement this in any of the projects I manage.
from contribute.jquery.org.
Node.js has been using more the verbose (SEMVER-MINOR) and (SEMVER-MAJOR) in their commit messages.
Click in the links you pasted, there is no SEMVER-*
there. They seem to be retroactively added when constructing the changelog for a release, they're not included in commit messages.
from contribute.jquery.org.
This information could be useful for changelog generation btw.
I don't think you can validate all commits this way, like misc, docs, etc; if such changes are not released with the project, they pretty much have nothing to do with semver terminology and because it would complicate contributing process for the beginners even more - it seems this responsibility should be on the maintainer, like sign-off tags.
I also don't think it should be requirement for everyone, team of any project should decide for itself.
I also wouldn't refuse to see example of the project with similar guide line.
from contribute.jquery.org.
I see the point @gibson042 makes about the semver level being more important than the component. It's not hard to see what component(s) are affected by a commit but you really have to understand the code that was changed to know its semver impact. Still, the first line of the commit is already pretty crowded so I'd prefer to see this info in the commit body as @leobalter suggested.
I wonder how the Node folks determine the semver level, it doesn't seem to be described in the commit so I guess they must review and determine it ex post facto.
from contribute.jquery.org.
Semver level is the most important detail of a commit, because it dictates the versions allowed to include it.
Can you explain how to expect to make use of this information?
Without more information, I agree with Scott - the commit message seems to be the wrong place to make any decisions related to backwards compatibility. For both QUnit and jQuery UI we spend a lot of time planning gradual migrations to introduce new features and remove old, commit messages were never part of that process.
Since you mention cherry-picking, maybe this is very specific to Core, with two stable releases managed in the same repository?
from contribute.jquery.org.
FWIW, I liked the idea of including semver info in the commit message, but my vote goes in line with what Leo and Dave suggested: in the commit body.
from contribute.jquery.org.
Since you mention cherry-picking, maybe this is very specific to Core, with two stable releases managed in the same repository?
There's honestly no difference between what Core does and what UI does in terms of managing multiple branches for parallel version releases. And api.jqueryui.com has an even larger spread of cherry-picking (historically it has been fairly common to cherry-pick commits across every version).
from contribute.jquery.org.
This semver idea is great. Flagging commits to tell my next version is great, and it involves a change log generation, where the message title can be prefixed, as in Node.
In the commits it can still reside at the body like I suggested earlier in a private email: "Semver: Major"
This is also very useful to determine my next npm version
.
This message standard would be of a great value to QUnit and its release process.
from contribute.jquery.org.
We need to identify commits that introduced breaking changes so that we don't backport them.
Shouldn't it be obvious enough when reviewing a patch to land in master if it can also land in another branch? The odds of landing breaking changes in master without a lot of scrutiny should be extremely low anyway.
I currently don't see the advantage of annotating commits with this information, when its is not relevant anymore after the commit landed in one or more branches.
from contribute.jquery.org.
Shouldn't it be obvious enough when reviewing a patch to land in master if it can also land in another branch?
This is not the situation we're in. We already have ~300 commits on master
that are newer than what's in the latest 2.1 release. They're there and some of them are breaking changes. We didn't pay that much attention as to which ones were breaking as we assumed they'll make it into jQuery 3.0.0
which will be a major release that's allowed to introduce breaking changes. Now we need to backport some (or most, to be decided) of those ~300 commits to jQuery 2.2.0
(and another ~300 commits from compat
to 1.12.0
) but without a way to quickly filter out the breaking ones we need to carefully examine every single one of them which is more time consuming.
from contribute.jquery.org.
Honestly, you should be examining them anyway. I think it's fine to define a standard for projects that want to use it. Since commit guidelines aren't requirements for all projects anyway, I'm trying to mostly stay out of this discussion since I don't want to implement this in the projects that I manage. But I don't think auto-porting 300 commits without manual review is a sane thing to do even with this additional information.
from contribute.jquery.org.
This seems more of a workflow or process issue then.
We didn't pay that much attention as to which ones were breaking as we assumed they'll make it into jQuery 3.0.0 which will be a major release that's allowed to introduce breaking changes.
That sounds scary. I wouldn't want to deal with that at all, no matter what the commit message claims. Even with a 3.0.0 release, how are you dealing with migration issues? Are you working on an upgrade guide already?
from contribute.jquery.org.
Even with a 3.0.0 release, how are you dealing with migration issues?
We did pay attention when landing them, we have tickets for Migrate for specific changes (some already merged), the major changes were also mentioned in the 3.0.0-alpha1 blog post. We also have the "Behavior change" label although I see it's not applied to every issue that should have it, e.g. jquery/jquery#1722. (@jquery/core do you think we may have more of those?).
Anyway, this info is not attached to commits so just by looking at a commit you may not always immediately say how to qualify it, you'll have to read the description, sometimes maybe open a linked issue to see more details. The problem is that requires way more time than just cherry-picking every commit that doesn't have semver-level: major
(or sth to that effect) in the commit description. Multiply that by 300 and take into account that we want to release those versions by the end of November...
FWIW, the fact that there are so many commits to take into account is why I've been skeptical to this idea of backporting almost every non-breaking commit to 1.12
/2.2
; it's just too much work, easy to overlook something and since there are even no plans of 1.12-rc.1
/2.2-rc.1
releases, the probability of a fatal mistake is IMO too high. I'd prefer to just backport the most important bugfixes (but to be very conservative with that) plus those that were meant for compat
only so that we don't have commits that will appear in no released versions (there are very few of those changes - see the list - and not everything on that list should be backported so it's not a problem).
from contribute.jquery.org.
Having dealt with the UI 1.8/1.9 release phase, which contained an order of magnitude more commits than the Core 1.12/2.2/3.0 release phase, I'd be really skeptical of trusting this info for a proper decision on which commits to merge. Also, your concern about only backporting the most important bug fixes makes me think this info won't help you at all anyway.
from contribute.jquery.org.
Also, your concern about only backporting the most important bug fixes makes me think this info won't help you at all anyway.
Yes, in that case it's alright to analyze every single commit. @gibson042 wants to backport as much as possible, though and it's very hard to do it then.
from contribute.jquery.org.
+1 for the commit body. I'd be okay with it in the subject, but as @gibson042 pointed out, we can use --grep
or similar to filter the logs.
from contribute.jquery.org.
The last project I was on we had some auto tagging release bots and we used
#patch #minor #major (and #pre...) To tell that bot how big of a bump
something would be.
The info was super useful.
I don't think we need to do this if we don't have automation for release,
but it could be useful to start doing and have jQuery release verify that
there aren't any commits that call for say a major or minor bump while we
are doing a patch release.
On Nov 3, 2015 9:13 AM, "Timmy Willison" [email protected] wrote:
+1 for the commit body. I'd be okay with it in the subject, but as
@gibson042 https://github.com/gibson042 pointed out, we can use --grep
or similar to filter the logs.—
Reply to this email directly or view it on GitHub
#130 (comment)
.
from contribute.jquery.org.
It looks like there's a rough consensus in favor of having this information, but having it in the body. I'm tentatively prepared to move forward on SemVer: {Major|Minor|Patch}
.
from contribute.jquery.org.
on a second thought, for consistency with npm version
, we should use the values in all lowercases: {major|minor|patch}
.
from contribute.jquery.org.
We didn't act on this, but if we do it should probably be at a project level. I still like the idea of marking these somehow, outside the cramped first line.
from contribute.jquery.org.
Related Issues (20)
- Style Guide: Context-changing methods as first method call HOT 2
- CLA Checker: Show time of attempted verification HOT 3
- Wrong link to the github repository for the http://sizzlejs.com/ website HOT 9
- Update CLA check text in maintainers guide HOT 2
- Deploying command is kind of confusing HOT 10
- fresh jQuery style guide
- Clarify the need to setup Wordpress locally HOT 5
- Commits and Pull Requests: Inconsistent with current workflow HOT 6
- Document focus problems in IE HOT 2
- JS styleguide: Replacement for onevar HOT 1
- Document consistency goods with files examples HOT 5
- Please clarify documentation issues in "How to Report Bugs" -> Where to Report HOT 4
- Don't require spaces inside expression parentheses HOT 2
- Plugin contribute HOT 1
- Adopt standard module (for new projects) HOT 14
- The JavaScript Style Guide incorrectly says all projects use JSHint HOT 3
- drag actions not working on microsoft touch screen laptops HOT 1
- Delete "Verify the Author Info and CLA" section HOT 1
- CLA link redirects to OpenJS Foundation page with no CLA in evidence HOT 1
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 contribute.jquery.org.