-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare to release version 3.4. Helps to fix Issue #95. #97
Prepare to release version 3.4. Helps to fix Issue #95. #97
Conversation
Please remove the commit for the 3.5pre version bump. That will be done separately and is not part of this task. |
3.4 / 2012-10-11 | ||
================== | ||
|
||
* Extension: Include changeset info in the Insert/Copy Build ID menuitem and in 'Customize Titlebar'. (#65) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the pull # instead of the issue #. Reason is that we have to be consistent and check-ins will have a pull but not necessarily an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for __Issue Number__s, because they are more descriptive, they are the goal, the drivers of development.
Pulls are tools of controlling - how the changes are accepted and merged into source.
Of course Pull Number is OK, when no Issue Number exists.
Other way of reasoning:
Pulls are closer to compare view (e.g. v3.2.2...v3.3), and issues are closer to milestones.
And release notes (history.md
) are closer to milestones, IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For another example see mozmill!
It's official repository is on GitHub, but it's tracker is bugzilla.mozilla.org.
Check the it's changelists on AMO, it uses bug numbers instead of pull numbers!
(The commit messages refers to bug numbers also - but this is not the subject here)
As I noted in my previous comment, the issue numbers are more informative than the pull request numbers.
If 3.4 going to be released without the Force compatibility enhancement (Issue #52 / Pull #82) then a version-string update to |
Updated description due to landings:
|
Updated description due to removed commit 0a16d69:
|
- MPL 2 landed - column resize landed
xabolcs commented:
Opened Pull #103. |
Updated description:
|
- privacyContext'ed screenshot landed
Updated description & commit range due to landings:
|
Should I provide here (for example in the description) AMO formatted Release Notes to avoid Markdown formatted strings being used on AMO? |
IIUC one pull may refer to zero, one, two… issues. I agree that the issue number(s) are more meaningful than the pull number (on hg.mozilla.org, each commit has either a bug number or NO BUG) but why not mention the pull number and also all the issues it fixes (or helps to fix)? |
- 'extensions.checkCompatibility' updated
Updated description & commit range due to landing:
|
Thanks! Currently almost all the numbers are issue #. Only Also the AMO strings are using issue #s (where exists, and the issue -> pull redirect does work). I think the pull request is up to date in the term of numbers. Should I do other changes or checks? |
Given that you have the best overview of pull requests at the moment it would be good to know which ones you would like to see in 3.4. How many remain before we can release the next version? |
Nice to have pulls:
|
Sorry for the late reply but I was on vacation for a while. So with the latest fix from #115 landed we should get out a new version of NTT as soon as possible. Would you mind to update this pull so we can get this version released? |
- GreD/CurProcD workaround for Bug 755724
Just updated the commit range to include the updated changelist + release date. Let 3.4 go! :) |
* Extension: Make columns of 'Customize Titlebar' dialog's tree resizable. (#25) | ||
* Extension: Add privacy context to saveScreenshot() due to Bug 795065. (#99) | ||
* Extension: Update checkCompatibility preferences for compatibility. (#103) | ||
* Extension: Use GreD instead CurProcD to reference GRE specific files. (#115) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order of the items look incorrect. We usually sort descending with the most recent fix at the top. Can you please fix that?
- reverse changelist - maxVersion
@whimboo |
Hi!
Please do not stash the3.5pre
version bump commit with the others!Merge this pull request as 2 commit: one for the release notes and one for version bump.
There should be a commit where the
<version>
is3.4
ininstall.rdf
!That commit should be tagged as
v3.4
!Release Notes contains:
Nice to have (but not blocking!) fixes (in priority order):
about:support
(Issue copy about:support to pastebin menu entry is broken #86 / Pull Use pastebin.m.o with FormData. Fixes #86. #93)Please note that the issue numbers in the commit are the issue numbers instead pull numbers!
AMO Release Notes strings: