You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <ju...@gmail.com> on 2015/01/29 20:09:48 UTC
"next-release" jira label
Do you think it would be useful to have a “next-release” jira label, to indicate issues that are a priority? I’ve tried setting the “fix version” of some open issues to “1.1-incubating” (i.e. a release that we haven’t started work on yet) but I that’s confusing.
(I’m thinking of https://issues.apache.org/jira/browse/CALCITE-579 <https://issues.apache.org/jira/browse/CALCITE-579> and https://issues.apache.org/jira/browse/CALCITE-507 <https://issues.apache.org/jira/browse/CALCITE-507>.)
Julian
Re: "next-release" jira label
Posted by Ted Dunning <te...@gmail.com>.
On Thu, Jan 29, 2015 at 6:00 PM, Julian Hyde <ju...@gmail.com> wrote:
> However, what you describe would work for projects with a more defined
> release roadmap.
>
It works either way. The only diff is what you call the catch-all next
release and whether you move things out.
Re: "next-release" jira label
Posted by Julian Hyde <ju...@gmail.com>.
For various reasons, Calcite is running in an "agile" mode: time-based releases, not feature-based releases. We don't tend to plan releases or commit to delivering particular sets of features on particular dates. Instead we commit to keeping the code stable, making regular releases (approximately monthly), and to accepting (or at least considering) contributions in a timely manner. If a particular party needs feature X in a release by a particular date, they can achieve it by contributing it in time for that month's release.
However, what you describe would work for projects with a more defined release roadmap.
Julian
> On Jan 29, 2015, at 2:49 PM, Ted Dunning <te...@gmail.com> wrote:
>
> On Thu, Jan 29, 2015 at 2:24 PM, Julian Hyde <ju...@gmail.com> wrote:
>
>> Release numbers have a habit of changing just before a release, sometimes
>> we do a "quick" intermediate release, leaving some of the goals to the next
>> release
>
>
> JIRA actually does batch operations like this really well.
>
> Using a real release number is very nice because JIRA understands default
> ordering well. This makes the dashboards in JIRA very useful as you
> schedule issues to put in different releases.
>
>
> Having a next-release version in JIRA can work, but what I would recommend
> is that periodically, you pull all such JIRA's and triage them into an
> actual version number. If you need an emergency release, you can pull
> everything from a particular version number and batch move selected JIRA's
> all at once to the emergency patch.
Re: "next-release" jira label
Posted by Ted Dunning <te...@gmail.com>.
On Thu, Jan 29, 2015 at 2:24 PM, Julian Hyde <ju...@gmail.com> wrote:
> Release numbers have a habit of changing just before a release, sometimes
> we do a "quick" intermediate release, leaving some of the goals to the next
> release
JIRA actually does batch operations like this really well.
Using a real release number is very nice because JIRA understands default
ordering well. This makes the dashboards in JIRA very useful as you
schedule issues to put in different releases.
Having a next-release version in JIRA can work, but what I would recommend
is that periodically, you pull all such JIRA's and triage them into an
actual version number. If you need an emergency release, you can pull
everything from a particular version number and batch move selected JIRA's
all at once to the emergency patch.
Re: "next-release" jira label
Posted by James Taylor <ja...@apache.org>.
On Thu, Jan 29, 2015 at 11:57 AM, Julian Hyde <ju...@hydromatic.net> wrote:
>
>> On Jan 29, 2015, at 11:48 AM, James Taylor <ja...@apache.org> wrote:
>>
>> - always release out of a branch and never out of master
>
> We just started doing this in the 1.0 release. The issue I struggled with is this: suppose that you fix a bug on the 1.0 branch before you release 1.0 but after you have branched from master. After the release you will apply the patch for that bug to the master branch. But since other changes have been made to the master branch, the commit hash will be different.
>
> So... which commit hash do you use when you mark the bug fixed? The one on the 1.0 branch or the one of the master branch?
The Jenkins builds add comments with the commit hash and files changed
when the build is complete after the commit, so we'll end up with one
comment per branch checked in.
>
>
>> - set the Fixed Version at the time it is committed to the release(s)
>> that'll contain the fix. This way we can easily run a query that shows
>> all the JIRAs fixed in a given release.
>
> So, when you mark the bug fixed, and commit the patch to git (it might be to master or to the branch) you don't record the fix version? If so, how do you figure out which bugs were fixed in a release?
When the bug is resolved by the person who made the fix, they set the
fix version(s) too (where the fix version corresponds to the release
in which the fix will appear).
>
> Our process is to mark the bug fixed and set its fix version when the patch is committed to master, then mark the bug closed (with the same fix version) when the release is made.
>
> Not to say that our process is better. Appreciate hearing how others do it.
>
Yep, lots of ways to do it.
> Julian
>
Re: "next-release" jira label
Posted by Julian Hyde <ju...@hydromatic.net>.
> On Jan 29, 2015, at 11:48 AM, James Taylor <ja...@apache.org> wrote:
>
> - always release out of a branch and never out of master
We just started doing this in the 1.0 release. The issue I struggled with is this: suppose that you fix a bug on the 1.0 branch before you release 1.0 but after you have branched from master. After the release you will apply the patch for that bug to the master branch. But since other changes have been made to the master branch, the commit hash will be different.
So... which commit hash do you use when you mark the bug fixed? The one on the 1.0 branch or the one of the master branch?
> - set the Fixed Version at the time it is committed to the release(s)
> that'll contain the fix. This way we can easily run a query that shows
> all the JIRAs fixed in a given release.
So, when you mark the bug fixed, and commit the patch to git (it might be to master or to the branch) you don't record the fix version? If so, how do you figure out which bugs were fixed in a release?
Our process is to mark the bug fixed and set its fix version when the patch is committed to master, then mark the bug closed (with the same fix version) when the release is made.
Not to say that our process is better. Appreciate hearing how others do it.
Julian
Re: "next-release" jira label
Posted by James Taylor <ja...@apache.org>.
Different projects do it differently, but the way we do it in Phoenix is:
- create a branch per minor and major release
- create tags per patch release
- always release out of a branch and never out of master
- set the Fixed Version at the time it is committed to the release(s)
that'll contain the fix. This way we can easily run a query that shows
all the JIRAs fixed in a given release.
- use the Sprint feature in the Agile JIRA feature (INFRA can enable
this for you) to set the "target" version for a given JIRA.
The last bit we haven't been great about doing, but I haven't found a
better way of indicating the Target Version of a JIRA.
HTH. Thanks,
James
On Thu, Jan 29, 2015 at 11:35 AM, Julian Hyde <ju...@gmail.com> wrote:
> I like it. Let's just call it "next". And as you say, we can have several like this, such as "next major".
>
>> On Jan 29, 2015, at 11:30 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>
>> What if we add "JIRA version" that is literally named "next release"?
>> To be more flexible we could have a couple of "next" versions (see below).
>>
>> We set "fix version" == "next release version".
>> Roadmap tab in JIRA
>> (https://issues.apache.org/jira/browse/CALCITE/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel)
>> shows the number of open/fixed versions.
>>
>> When you click "release version" in jira, it will warn you on every
>> non-fixed issue and suggest to move it to another version (here the
>> second "next" could be helpful)
>>
>> Does that make sense?
>>
>> If we go with label approach, we'll have to manually track labels,
>> remove them from fixed issues, etc.
>>
>> Vladimir
>
Re: "next-release" jira label
Posted by Julian Hyde <ju...@gmail.com>.
I like it. Let's just call it "next". And as you say, we can have several like this, such as "next major".
> On Jan 29, 2015, at 11:30 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> What if we add "JIRA version" that is literally named "next release"?
> To be more flexible we could have a couple of "next" versions (see below).
>
> We set "fix version" == "next release version".
> Roadmap tab in JIRA
> (https://issues.apache.org/jira/browse/CALCITE/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel)
> shows the number of open/fixed versions.
>
> When you click "release version" in jira, it will warn you on every
> non-fixed issue and suggest to move it to another version (here the
> second "next" could be helpful)
>
> Does that make sense?
>
> If we go with label approach, we'll have to manually track labels,
> remove them from fixed issues, etc.
>
> Vladimir
Re: "next-release" jira label
Posted by Vladimir Sitnikov <si...@gmail.com>.
> Well, we *try* to provide timely releases. Sometimes we succeed. :)
When I say << "release" versions in JIRA>> I mean pressing "release
version" in the JIRA itself.
I think it is not integrated with git/maven stuff, so you can have
arbitrary names/statuses of versions in JIRA.
Vladimir
Re: "next-release" jira label
Posted by Vladimir Sitnikov <si...@gmail.com>.
What if we add "JIRA version" that is literally named "next release"?
To be more flexible we could have a couple of "next" versions (see below).
We set "fix version" == "next release version".
Roadmap tab in JIRA
(https://issues.apache.org/jira/browse/CALCITE/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel)
shows the number of open/fixed versions.
When you click "release version" in jira, it will warn you on every
non-fixed issue and suggest to move it to another version (here the
second "next" could be helpful)
Does that make sense?
If we go with label approach, we'll have to manually track labels,
remove them from fixed issues, etc.
Vladimir
Re: "next-release" jira label
Posted by Julian Hyde <ju...@gmail.com>.
Well, we *try* to provide timely releases. Sometimes we succeed. :)
My worry is that we would forget to set the release correctly when we mark the issue fixed. And I wanted a lightweight process so that a developer could see what to work on next. Release numbers have a habit of changing just before a release, sometimes we do a "quick" intermediate release, leaving some of the goals to the next release. With the "next-release" label we would not have to update all those jira cases.
Julian
> On Jan 29, 2015, at 11:13 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> I’ve tried setting the “fix version” of some open issues to “1.1-incubating” (i.e. a release that we haven’t started work on yet) but I that’s confusing.
>
> What is confusing?
> I believe it is usable provided we timely "release" versions in JIRA.
>
> Vladimir
Re: "next-release" jira label
Posted by Vladimir Sitnikov <si...@gmail.com>.
> I’ve tried setting the “fix version” of some open issues to “1.1-incubating” (i.e. a release that we haven’t started work on yet) but I that’s confusing.
What is confusing?
I believe it is usable provided we timely "release" versions in JIRA.
Vladimir