Just thinking ahead a bit: since 4.0 will really be a pretty big
release, we have mentioned on the list a few times the ideas of
alphas/betas.
I like the idea of trying to iterate towards a release here, as I
think there will be numerous packaging and documentation issues,
forget about
any real bugs or API problems.

I was thinking that in order to actually get people to use and test
these things, we should try to make them more than just nightly
builds.

Here are some quick ideas:

Alpha:
  We won't change the index format unless necessary to fix a bug

Beta:
  We won't change public apis or configuration files unless necessary
to fix a bug

Any opinions?
We could always add more caveats if needed, but the less the better.

--
lucidimagination.com

---------------------------------------------------------------------

I agree.

Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
4.0-alpha we'll tag all the issues that are expected to change the index
format, and 4.0-beta all the issues that require API changes?

Shai

On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:

> Just thinking ahead a bit: since 4.0 will really be a pretty big
> release, we have mentioned on the list a few times the ideas of
> alphas/betas.
> I like the idea of trying to iterate towards a release here, as I
> think there will be numerous packaging and documentation issues,
> forget about
> any real bugs or API problems.
>
> I was thinking that in order to actually get people to use and test
> these things, we should try to make them more than just nightly
> builds.
>
> Here are some quick ideas:
>
> Alpha:
>  We won't change the index format unless necessary to fix a bug
>
> Beta:
>  We won't change public apis or configuration files unless necessary
> to fix a bug
>
> Any opinions?
> We could always add more caveats if needed, but the less the better.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Seems like a good idea to me.

Martijn

On 6 March 2012 07:42, Shai Erera <[EMAIL PROTECTED]> wrote:

> I agree.
>
> Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
> 4.0-alpha we'll tag all the issues that are expected to change the index
> format, and 4.0-beta all the issues that require API changes?
>
> Shai
>
>
> On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>
>> Just thinking ahead a bit: since 4.0 will really be a pretty big
>> release, we have mentioned on the list a few times the ideas of
>> alphas/betas.
>> I like the idea of trying to iterate towards a release here, as I
>> think there will be numerous packaging and documentation issues,
>> forget about
>> any real bugs or API problems.
>>
>> I was thinking that in order to actually get people to use and test
>> these things, we should try to make them more than just nightly
>> builds.
>>
>> Here are some quick ideas:
>>
>> Alpha:
>>  We won't change the index format unless necessary to fix a bug
>>
>> Beta:
>>  We won't change public apis or configuration files unless necessary
>> to fix a bug
>>
>> Any opinions?
>> We could always add more caveats if needed, but the less the better.
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
--
Met vriendelijke groet,

Martijn van Groningen

+1 lets get all blockers in and shoot for it

simon

On Tue, Mar 6, 2012 at 8:06 AM, Martijn v Groningen
<[EMAIL PROTECTED]> wrote:
> Seems like a good idea to me.
>
> Martijn
>
>
> On 6 March 2012 07:42, Shai Erera <[EMAIL PROTECTED]> wrote:
>>
>> I agree.
>>
>> Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
>> 4.0-alpha we'll tag all the issues that are expected to change the index
>> format, and 4.0-beta all the issues that require API changes?
>>
>> Shai
>>
>>
>> On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>>>
>>> Just thinking ahead a bit: since 4.0 will really be a pretty big
>>> release, we have mentioned on the list a few times the ideas of
>>> alphas/betas.
>>> I like the idea of trying to iterate towards a release here, as I
>>> think there will be numerous packaging and documentation issues,
>>> forget about
>>> any real bugs or API problems.
>>>
>>> I was thinking that in order to actually get people to use and test
>>> these things, we should try to make them more than just nightly
>>> builds.
>>>
>>> Here are some quick ideas:
>>>
>>> Alpha:
>>>  We won't change the index format unless necessary to fix a bug
>>>
>>> Beta:
>>>  We won't change public apis or configuration files unless necessary
>>> to fix a bug
>>>
>>> Any opinions?
>>> We could always add more caveats if needed, but the less the better.
>>>
>>> --
>>> lucidimagination.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>
>
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen

---------------------------------------------------------------------

+1

On Tue, Mar 6, 2012 at 4:29 AM, Simon Willnauer
<[EMAIL PROTECTED]> wrote:
> +1 lets get all blockers in and shoot for it
>
> simon
>
> On Tue, Mar 6, 2012 at 8:06 AM, Martijn v Groningen
> <[EMAIL PROTECTED]> wrote:
>> Seems like a good idea to me.
>>
>> Martijn
>>
>>
>> On 6 March 2012 07:42, Shai Erera <[EMAIL PROTECTED]> wrote:
>>>
>>> I agree.
>>>
>>> Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
>>> 4.0-alpha we'll tag all the issues that are expected to change the index
>>> format, and 4.0-beta all the issues that require API changes?
>>>
>>> Shai
>>>
>>>
>>> On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Just thinking ahead a bit: since 4.0 will really be a pretty big
>>>> release, we have mentioned on the list a few times the ideas of
>>>> alphas/betas.
>>>> I like the idea of trying to iterate towards a release here, as I
>>>> think there will be numerous packaging and documentation issues,
>>>> forget about
>>>> any real bugs or API problems.
>>>>
>>>> I was thinking that in order to actually get people to use and test
>>>> these things, we should try to make them more than just nightly
>>>> builds.
>>>>
>>>> Here are some quick ideas:
>>>>
>>>> Alpha:
>>>>  We won't change the index format unless necessary to fix a bug
>>>>
>>>> Beta:
>>>>  We won't change public apis or configuration files unless necessary
>>>> to fix a bug
>>>>
>>>> Any opinions?
>>>> We could always add more caveats if needed, but the less the better.
>>>>
>>>> --
>>>> lucidimagination.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>
>>
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Martijn van Groningen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

: I was thinking that in order to actually get people to use and test
: these things, we should try to make them more than just nightly
: builds.

agreed ... your bug criteria below makes sense, and i think it would be
help promote testing & adoption if we treated the alpha/beta release(s) as
*true* releases - voted on and published to the mirrors.

: Alpha:
:   We won't change the index format unless necessary to fix a bug
:
: Beta:
:   We won't change public apis or configuration files unless necessary
: to fix a bug
-Hoss

---------------------------------------------------------------------

+1

Mike McCandless

http://blog.mikemccandless.com

On Mon, Mar 5, 2012 at 10:20 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
> Just thinking ahead a bit: since 4.0 will really be a pretty big
> release, we have mentioned on the list a few times the ideas of
> alphas/betas.
> I like the idea of trying to iterate towards a release here, as I
> think there will be numerous packaging and documentation issues,
> forget about
> any real bugs or API problems.
>
> I was thinking that in order to actually get people to use and test
> these things, we should try to make them more than just nightly
> builds.
>
> Here are some quick ideas:
>
> Alpha:
>  We won't change the index format unless necessary to fix a bug
>
> Beta:
>  We won't change public apis or configuration files unless necessary
> to fix a bug
>
> Any opinions?
> We could always add more caveats if needed, but the less the better.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

Hi,

 

I was thinking about that already: Currently we have lots of issues with
"Affects Version" = 4.0 and then "fix version" also 4.0. This makes no sense
in my opinion and also confuses users after the release of 4.0. I would
prefer to change all those issues to have an affects version that is
something different, like "4.x", "4.pre",.

 

The problem we have now is that when 4.0 is out and somebody opens a bug
against it, it will also have 4.0. So I would like to change all those
affects versions to something telling that its not affecting 3.x, but
something inbetween, a prerelease-state. So all those bugs would have 4.pre
with a fix of 4.0, later bugs will have 4.0 with fix version 4.1, 4.2,.

 

What do you think? What "version" name for unreleased trunk would you
prefer?

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: [EMAIL PROTECTED]

 

From: Shai Erera [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 06, 2012 7:43 AM
To: [EMAIL PROTECTED]
Subject: Re: ideas for alphas/betas?

 

I agree.

Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
4.0-alpha we'll tag all the issues that are expected to change the index
format, and 4.0-beta all the issues that require API changes?

Shai

On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:

Just thinking ahead a bit: since 4.0 will really be a pretty big
release, we have mentioned on the list a few times the ideas of
alphas/betas.
I like the idea of trying to iterate towards a release here, as I
think there will be numerous packaging and documentation issues,
forget about
any real bugs or API problems.

I was thinking that in order to actually get people to use and test
these things, we should try to make them more than just nightly
builds.

Here are some quick ideas:

Alpha:
 We won't change the index format unless necessary to fix a bug

Beta:
 We won't change public apis or configuration files unless necessary
to fix a bug

Any opinions?
We could always add more caveats if needed, but the less the better.

--
lucidimagination.com

---------------------------------------------------------------------

 

I think "Affects version" applies only to what's been released. If a
bug is discovered on trunk it shouldn't have any "affects version" and
only "fix for".

Once you make a release, even a rc, the affects field can point to it
(4.0rc1, 4.0rc2...).

Dawid

On Tue, Mar 6, 2012 at 8:58 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> I was thinking about that already: Currently we have lots of issues with
> “Affects Version” = 4.0 and then “fix version” also 4.0. This makes no sense
> in my opinion and also confuses users after the release of 4.0. I would
> prefer to change all those issues to have an affects version that is
> something different, like “4.x”, “4.pre”,…
>
>
>
> The problem we have now is that when 4.0 is out and somebody opens a bug
> against it, it will also have 4.0. So I would like to change all those
> affects versions to something telling that its not affecting 3.x, but
> something inbetween, a prerelease-state. So all those bugs would have 4.pre
> with a fix of 4.0, later bugs will have 4.0 with fix version 4.1, 4.2,���
>
>
>
> What do you think? What “version” name for unreleased trunk would you
> prefer?
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [EMAIL PROTECTED]
>
>
>
> From: Shai Erera [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 06, 2012 7:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ideas for alphas/betas?
>
>
>
> I agree.
>
> Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
> 4.0-alpha we'll tag all the issues that are expected to change the index
> format, and 4.0-beta all the issues that require API changes?
>
> Shai
>
> On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>
> Just thinking ahead a bit: since 4.0 will really be a pretty big
> release, we have mentioned on the list a few times the ideas of
> alphas/betas.
> I like the idea of trying to iterate towards a release here, as I
> think there will be numerous packaging and documentation issues,
> forget about
> any real bugs or API problems.
>
> I was thinking that in order to actually get people to use and test
> these things, we should try to make them more than just nightly
> builds.
>
> Here are some quick ideas:
>
> Alpha:
>  We won't change the index format unless necessary to fix a bug
>
> Beta:
>  We won't change public apis or configuration files unless necessary
> to fix a bug
>
> Any opinions?
> We could always add more caveats if needed, but the less the better.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Tue, Mar 6, 2012 at 12:16 PM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:
> I think "Affects version" applies only to what's been released. If a
> bug is discovered on trunk it shouldn't have any "affects version" and
> only "fix for".
>

+1

---------------------------------------------------------------------

I agree with that it might be better to have no affects version. But having an affects version allows us to mark issues only relevant to the 4.x branch. Otherwise I cannot sort for issues that only affect 4.x, but have not yet a fix version.

For me it is easy to remove all Affects Version = 4.0 markers, but that’s destructive. If I add a new version (4.pre) and then update all affects versions to this new one, I loose nothing.

That’s the idea.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Dawid Weiss
> Sent: Tuesday, March 06, 2012 9:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ideas for alphas/betas?
>
> I think "Affects version" applies only to what's been released. If a bug is
> discovered on trunk it shouldn't have any "affects version" and only "fix for".
>
> Once you make a release, even a rc, the affects field can point to it (4.0rc1,
> 4.0rc2...).
>
> Dawid
>
> On Tue, Mar 6, 2012 at 8:58 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >
> >
> > I was thinking about that already: Currently we have lots of issues
> > with “Affects Version” = 4.0 and then “fix version” also 4.0. This
> > makes no sense in my opinion and also confuses users after the release
> > of 4.0. I would prefer to change all those issues to have an affects
> > version that is something different, like “4.x”, “4.pre”,…
> >
> >
> >
> > The problem we have now is that when 4.0 is out and somebody opens a
> > bug against it, it will also have 4.0. So I would like to change all
> > those affects versions to something telling that its not affecting
> > 3.x, but something inbetween, a prerelease-state. So all those bugs
> > would have 4.pre with a fix of 4.0, later bugs will have 4.0 with fix
> > version 4.1, 4.2,…
> >
> >
> >
> > What do you think? What “version” name for unreleased trunk would you
> > prefer?
> >
> >
> >
> > -----
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: [EMAIL PROTECTED]
> >
> >
> >
> > From: Shai Erera [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 06, 2012 7:43 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: ideas for alphas/betas?
> >
> >
> >
> > I agree.
> >
> > Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
> > 4.0-alpha we'll tag all the issues that are expected to change the
> > index format, and 4.0-beta all the issues that require API changes?
> >
> > Shai
> >
> > On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
> >
> > Just thinking ahead a bit: since 4.0 will really be a pretty big
> > release, we have mentioned on the list a few times the ideas of
> > alphas/betas.
> > I like the idea of trying to iterate towards a release here, as I
> > think there will be numerous packaging and documentation issues,
> > forget about any real bugs or API problems.
> >
> > I was thinking that in order to actually get people to use and test
> > these things, we should try to make them more than just nightly
> > builds.
> >
> > Here are some quick ideas:
> >
> > Alpha:
> >  We won't change the index format unless necessary to fix a bug
> >
> > Beta:
> >  We won't change public apis or configuration files unless necessary
> > to fix a bug
> >
> > Any opinions?
> > We could always add more caveats if needed, but the less the better.
> >
> > --
> > lucidimagination.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------

> relevant to the 4.x branch. Otherwise I cannot sort for issues that only affect 4.x, but have not yet a fix version.

If an issue doesn't have a "fix for" then it's a problem with the
issue's description I think (that should be fixed?).

I admit the concept of affects/fix for was unclear to me at the
beginning when I was starting with Jira (we have our own install in
Carrot2). What I explained is what we've come to agree on and is based
on trial-and-error really. It just worked best for us. Having "affects
version" set to a non-released artefact name is not really informative
and only pollutes the set of suggestions with names that are not
really pointing to anything.

There is the "labels" field where you can set arbitrary markers if you
so desire.

Dawid

>
> For me it is easy to remove all Affects Version = 4.0 markers, but that’s destructive. If I add a new version (4.pre) and then update all affects versions to this new one, I loose nothing.
>
> That’s the idea.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [EMAIL PROTECTED]
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
>> Dawid Weiss
>> Sent: Tuesday, March 06, 2012 9:16 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: ideas for alphas/betas?
>>
>> I think "Affects version" applies only to what's been released. If a bug is
>> discovered on trunk it shouldn't have any "affects version" and only "fix for".
>>
>> Once you make a release, even a rc, the affects field can point to it (4.0rc1,
>> 4.0rc2...).
>>
>> Dawid
>>
>> On Tue, Mar 6, 2012 at 8:58 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> >
>> >
>> > I was thinking about that already: Currently we have lots of issues
>> > with “Affects Version” = 4.0 and then “fix version” also 4.0. This
>> > makes no sense in my opinion and also confuses users after the release
>> > of 4.0. I would prefer to change all those issues to have an affects
>> > version that is something different, like “4.x”, ���4.pre”,…
>> >
>> >
>> >
>> > The problem we have now is that when 4.0 is out and somebody opens a
>> > bug against it, it will also have 4.0. So I would like to change all
>> > those affects versions to something telling that its not affecting
>> > 3.x, but something inbetween, a prerelease-state. So all those bugs
>> > would have 4.pre with a fix of 4.0, later bugs will have 4.0 with fix
>> > version 4.1, 4.2,…
>> >
>> >
>> >
>> > What do you think? What “version” name for unreleased trunk would you
>> > prefer?
>> >
>> >
>> >
>> > -----
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: [EMAIL PROTECTED]
>> >
>> >
>> >
>> > From: Shai Erera [mailto:[EMAIL PROTECTED]]
>> > Sent: Tuesday, March 06, 2012 7:43 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: ideas for alphas/betas?
>> >
>> >
>> >
>> > I agree.
>> >
>> > Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
>> > 4.0-alpha we'll tag all the issues that are expected to change the
>> > index format, and 4.0-beta all the issues that require API changes?
>> >
>> > Shai
>> >
>> > On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <[EMAIL PROTECTED]> wrote:
>> >
>> > Just thinking ahead a bit: since 4.0 will really be a pretty big
>> > release, we have mentioned on the list a few times the ideas of
>> > alphas/betas.
>> > I like the idea of trying to iterate towards a release here, as I
>> > think there will be numerous packaging and documentation issues,
>> > forget about any real bugs or API problems.
>> >
>> > I was thinking that in order to actually get people to use and test
>> > these things, we should try to make them more than just nightly
>> > builds.
>> >
>> > Here are some quick ideas:
>> >
>> > Alpha:
>> >  We won't change the index format unless necessary to fix a bug
>> >
>> > Beta:
>> >  We won't change public apis or configuration files unless necessary
>>

: I agree with that it might be better to have no affects version. But
: having an affects version allows us to mark issues only relevant to the
: 4.x branch. Otherwise I cannot sort for issues that only affect 4.x, but
: have not yet a fix version.
:
: For me it is easy to remove all Affects Version = 4.0 markers, but
: that’s destructive. If I add a new version (4.pre) and then update all
: affects versions to this new one, I loose nothing.

I agree with you ... i would suggest using "4x" or "4x_unreleased" as a
version name for use in the "affects" field anywhere "4.0" is currently
used.

labels/tags are useful for many things to help organize/categorize
issues -- but i think a "version" really makes sense for this particular
type of categorization -- particularly because of how it shows up in list
views & reports (and how versions "sort")
-Hoss

On Tue, Mar 6, 2012 at 1:42 AM, Shai Erera <[EMAIL PROTECTED]> wrote:
> I agree.
>
> Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
> 4.0-alpha we'll tag all the issues that are expected to change the index
> format, and 4.0-beta all the issues that require API changes?
>

I have no opinion on the actual JIRA tagging, but I think Hoss has a
good point that it would be better if we looked at alphas/betas as
"real releases"... ideally our first alpha release would be exactly
the same as our real 4.0 release, but we are just being realistic and
at the same time marking some caveats so that users know its a big
scary change.

So I'm not sure we should intentionally try to delay/bucket any issues
to alpha or beta, I think we should try to make it great from the
start... these 'guarantees' are just to help increase adoption and
testing.

--
lucidimagination.com

---------------------------------------------------------------------

>
> I admit the concept of affects/fix for was unclear to me at the
> beginning when I was starting with Jira (we have our own install in
> Carrot2). What I explained is what we've come to agree on and is based
> on trial-and-error really. It just worked best for us. Having "affects
> version" set to a non-released artefact name is not really informative
> and only pollutes the set of suggestions with names that are not
> really pointing to anything.
>

The way it works in practice is that we set both "affects version" and "fix
version" mostly for bugs found in the already released software, while for
new features and refactorings, we set only the "fix version". In both
cases, the "fix version" denotes the version in which we'd like to ship the
bug fix or new feature. With this schema, a simple search of issues with a
specific "fix version" shows how much progress we made towards the release.
One thing to watch for is issues without "fix version", which can easily
get forgotten/lost.

At one organization I worked for (size of software and team comparable to
Lucene/Solr), we used the above system with all alpha and RC releases
defined in JIRA. New alpha/RC were added to JIRA at the point of releasing
the current alpha/RC. This system was indispensable for devs and QA to
track which bugs and features they should expect to see fixed in the
specific release. At some point, if no issues were to be fixed in some RC,
the RC would become the official stable release. JIRA lets you merge
several versions (alpha/RCs) into one, and this would usually be done after
the official release to get rid of the intermediate internal milestones.

>From what I see, Lucene/Solr has a very similar process, so defining one or
more 4.0 alpha / beta releases in JIRA and then scheduling bugs and
features for it ("fix version") should work :-)

Staszek

2012/3/7 Robert Muir <[EMAIL PROTECTED]>

> On Tue, Mar 6, 2012 at 1:42 AM, Shai Erera <[EMAIL PROTECTED]> wrote:
> > I agree.
> >
> > Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
> > 4.0-alpha we'll tag all the issues that are expected to change the index
> > format, and 4.0-beta all the issues that require API changes?
> >
>
> I have no opinion on the actual JIRA tagging, but I think Hoss has a
> good point that it would be better if we looked at alphas/betas as
> "real releases"... ideally our first alpha release would be exactly
> the same as our real 4.0 release, but we are just being realistic and
> at the same time marking some caveats so that users know its a big
> scary change.
>
> So I'm not sure we should intentionally try to delay/bucket any issues
> to alpha or beta, I think we should try to make it great from the
> start... these 'guarantees' are just to help increase adoption and
> testing.
>

+1, as also Simon was saying let's go fixing the blockers and start working
on the alpha release process.

Tommaso
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

On 7 March 2012 15:42, Tommaso Teofili <[EMAIL PROTECTED]> wrote:
>
>
> 2012/3/7 Robert Muir <[EMAIL PROTECTED]>
>>
>> On Tue, Mar 6, 2012 at 1:42 AM, Shai Erera <[EMAIL PROTECTED]> wrote:
>> > I agree.
>> >
>> > Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
>> > 4.0-alpha we'll tag all the issues that are expected to change the index
>> > format, and 4.0-beta all the issues that require API changes?
>> >
>>
>> I have no opinion on the actual JIRA tagging, but I think Hoss has a
>> good point that it would be better if we looked at alphas/betas as
>> "real releases"... ideally our first alpha release would be exactly
>> the same as our real 4.0 release, but we are just being realistic and
>> at the same time marking some caveats so that users know its a big
>> scary change.
>>
>> So I'm not sure we should intentionally try to delay/bucket any issues
>> to alpha or beta, I think we should try to make it great from the
>> start... these 'guarantees' are just to help increase adoption and
>> testing.
>
>
> +1, as also Simon was saying let's go fixing the blockers and start working
> on the alpha release process.
>

It's of course very cool if you could start by "make it great from the start",
but that would take more time I would rather be realistic and start
providing some tags
in quick iterations.

Even if it has known issues, that's acceptable for an Alpha release
but at least you start
getting more feedback, especially on the API which you obviously don't
want to alter
significantly just before the final.

Regards,
Sanne

---------------------------------------------------------------------