Changes in 3212 (or any release)?

We used to have that nice link to a tracker search that listed new features/fixed bugs for a new EAP release.

Is that possible somehow with Jira?
It seems I can't define a query "build > 3200 and build < 3213".

E.g. I haven't found any issue at all for the new feature that checks needed path variables when loading a project and haven't seen it mentioned in any notes.

12 comments
Comment actions Permalink

In article <18349102.1108052591323.JavaMail.itn@is.intellij.net>,
Jon Steelman <no_mail@jetbrains.com> wrote:

+1


yeah complain to Jira, unfortunately the fixed in build field is custom
and JB added it, there seems to be no way to search based on custom
fields in the search section of the editor.

R

0
Comment actions Permalink

yeah complain to Jira, unfortunately the fixed in build field is custom
and JB added it, there seems to be no way to search based on custom
fields in the search section of the editor.


Robert, what you are saying is wrong. In JIRA you easily can define
versions, e.g. "Build 3212". When you release it, everybody can see the
changes at one glance. It's not JIRA's fault; it just is used incorrectly -
or at least not as it was designed.

Tom

0
Comment actions Permalink

In article <cug3a5$puu$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <I@HateSpam.de> wrote:

yeah complain to Jira, unfortunately the fixed in build field is custom
and JB added it, there seems to be no way to search based on custom
fields in the search section of the editor.


Robert, what you are saying is wrong. In JIRA you easily can define
versions, e.g. "Build 3212". When you release it, everybody can see the
changes at one glance. It's not JIRA's fault; it just is used incorrectly -
or at least not as it was designed.


Ok then someone fix it, because doing a search for > 3200 < 3213 can't
be done... or am I wrong there as well?

All I'm saying is that there doesn't seem to be a way to search custom
fields, at least not the the way I'd want to.

R

0
Comment actions Permalink

Robert S. Sfeir wrote:

>yeah complain to Jira, unfortunately the fixed in build field is custom
>and JB added it, there seems to be no way to search based on custom
>fields in the search section of the editor.
>

>

On a related matter, I've just spent 20 minutes with JIRA web interface,
to post 2 bugs, and check a dozen other issues modified recently.
It used to take 2 minutes, at most, with the newsgroups, and I could
read 100% of all the issues posted.

Because of this, I can't give useful feedback, I can't give comments,
and I'm sure I'll post loads of duplicates.
Too bad. I really wanted to help.


Alain

0
Comment actions Permalink

In article <cug3a5$puu$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <I@HateSpam.de> wrote:

yeah complain to Jira, unfortunately the fixed in build field is custom
and JB added it, there seems to be no way to search based on custom
fields in the search section of the editor.


Robert, what you are saying is wrong. In JIRA you easily can define
versions, e.g. "Build 3212". When you release it, everybody can see the
changes at one glance.


This is assuming also you have a full release, so Irida is the release
right now, what you're suggesting (if I'm not wrong) that JetBrains
create a version for every EAP. You know the kind of work this takes?
Everytime someone fixes something for their nightly build, they have to
create a fixed in, and you can't report bugs against this fix since we
don't have it, so you'll end up with a bunch of garbage you have to weed
through when reporting a bug per version.

Jira may be setup wrong for how Jira works, but Jira's idea of how it
should work is wrong. I don't see a notion of builds, rather versions,
so if you have an iterative process, which is what JetBrains is doing in
a way, it doesn't work for that purpose.

R

0
Comment actions Permalink

Maybe the JetBrains guys should take a look at how Omnicore took advantage of JIRA. Take a look at this:

http://jira.omnicore.com/secure/BrowseProject.jspa?id=10000&report=changelog

Tongue in the cheek ;)

0
Comment actions Permalink

In article <29316029.1108054819148.JavaMail.itn@is.intellij.net>,
Marcus Brito <mbrito@gmail.com> wrote:

http://jira.omnicore.com/secure/BrowseProject.jspa?id=10000&report=changelog


Again though, Omnicore is not driving its builds like JB's EAP. Their
builds are roughly 4 months apart as far as I can tell, and the build
goes up by 1 every 4 months, not by 1 every day.

R

0
Comment actions Permalink

This is assuming also you have a full release, so Irida is the release
right now, what you're suggesting (if I'm not wrong) that JetBrains
create a version for every EAP.


Exactly.

> You know the kind of work this takes?

Yes, it's very easy to do.

Everytime someone fixes something for their nightly build, they have to
create a fixed in, and you can't report bugs against this fix since we
don't have it, so you'll end up with a bunch of garbage you have to weed
through when reporting a bug per version.


I don't understand you.

Jira may be setup wrong for how Jira works, but Jira's idea of how it
should work is wrong.


Builds are nothing different than versions. What's wrong with labeling a
(released) version "Irida 3200" or "Irida 3132"? The current working version
is, for example, labeled "Irida next build". Every solved issue is set to
Fixed in: "Irida next build". When it is released, it will be renamed to
"Irida 3149". We do this all the time, just takes a minute.

Tom

0
Comment actions Permalink

Yes, so I have thought it.

Tom

0
Comment actions Permalink

Robert, I don't want Jetbrains to create a new version for every (daily)
build, just for the released builds, which we could download.

Tom

0
Comment actions Permalink


Builds are nothing different than versions.


Yes they are depending on the context you put them in. If you're in an
iterative context a build is not a version, a build is simply a set of
features you put in to drive to the version. A version is a place where
you've reached your goal of integrating all the features. A version in
this case is Version 5.0 of IDEA.

What's wrong with labeling a
(released) version "Irida 3200" or "Irida 3132"?


(I don't work for JB so I'm just assuming here, and so are you I think)
because you'd have to generate one for each build from 3200 to 3212 and
on up until release of the actual version, and that gets so messy, you
want to scroll through that tiny multi select list in Jira to find your
build number and apply the problem to it? Like Jira's interface is not
complex enough.

The current working version
is, for example, labeled "Irida next build".


What if it's not in the next build? Look at the tracker Thomas, you
know that doesn't work. There are things fixed which are not in this
build, how do you then go back and mark that something was not in this
next build? What if you fix something, make a build, the build fails,
in the bean time you've labeled the build, and went to move on to the
next build, where do you file that? The next next build? What if
because of the delay in getting the build to build you want to include
the added fixes, then what?

Every solved issue is set to
Fixed in: "Irida next build". When it is released, it will be renamed to
"Irida 3149". We do this all the time, just takes a minute.


Making the change might be fine, but changing your whole work process
just to fit a bug tracker is just as bad as it can get for development.
A tracker should never drive how you develop and do your iterations, a
tracker should work the way you need it to work, not the other way
around.

R

0

Please sign in to leave a comment.