You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2019/11/20 15:01:55 UTC

Re: Thinking about release candidates

Hi,

Here's how I think about releasing vs doing another RC:

1) any release we put out will be defective (in some ways), because we're
releasing complicated things.

2) The question about whether to release or not, therefore, doesn't depend on
not finding issues.

3) The release question becomes, then, is it better for the community to have
this out (now), versus waiting a bit for a few more fixes/improvements?

It seems that this last question has to juggle conflicting goals / issues, such as

a) users want the fixes improvements, sooner than later (but if by later, we
mean a delay of a few days, probably doesn't matter)

b) users don't like to upgrade - it's potentially destabilizing, and "busy work"
usually.  So "bothering" our users with excessive upgrades isn't so good. 
Example: the new Java release system, where there's 1 long-term-stable release
followed by 2 short releases; I think most people don't bother with the short
term releases...

c) overall quality impression: we want our users to continue to feel their use
of our systems is "investible", that is they can invest their time and energy in
using these, with an expected level of quality - that the systems can be relied
on to deliver their promises.  Part of quality is the documentation, and how
"consumable" things are (this word encompasses many things, often around
concepts of how easy is it to climb the learning curve).  If the quality
impression drops, that could be a reason to do another RC.

Sorry if this is all completely obvious - I thought it might be worth saying :-)

-Marshall

On 11/19/2019 7:30 AM, Peter Klügl wrote:
> Hi,
>
>
> I have been thinking a lot about it since your mail and I was not yet
> able to decide about a new RC. Don't misunderstand me, there should of
> course be a new RC. Here's why I did not yet cancel the current RC:
>
>
> There was the new functionality for the explanation (debug info) of
> inlined rules, which is described in the two new paragraphs. I did not
> add a screenshot because I want to use it in practice before I decide
> where to put it in the perspective.
>
> The dictionary changes can be viewed as bug fixes since they adapt the
> default behavior to be more compatible with the users. Same is true for
> the improved literal string matches and the labels at macro action:
> (many) users thought it should behave in a certain way and thought they
> found a bug. So, I did not change the docs for it.
>
> The fact that I forgot about the type expression is really annoying.
>
>
> So I would mainly extend the syntax description for the type and add an
> example in the new RC.
>
>
> And here's the thing why I hesitate: The next thing I do is prepare an
> RC for Ruta 3.0.0, which will replace the current documentation which
> most users will look at. I assume that the extended documentation in
> 2.8.0 will hardly be read by anyone...
>
>
> Best,
>
>
> Peter
>
>
> Am 18.11.2019 um 19:53 schrieb Marshall Schor:
>> I looked at the svn change log since 2.7.0 was released (24 Feb 2019), and see
>> only one change: adding 2 paragraphs for Inlined Rules.
>>
>> So I don't think there is any doc about the new debug info for inlined rules, or
>> the enhanced Dictionary Matching, or the new default setting for dictRemoveWS,
>> or new support for labels at macro actions.
>>
>> I'll leave it up to you, but it seems to me that it would be worth another RC to
>> get the new stuff documented, into both the docbook and (also maybe?) any JavaDocs.
>>
>> -Marshall
>>
>>
>> On 11/18/2019 12:11 PM, Marshall Schor wrote:
>>> Hi,
>>>
>>> Did the documentation for RUTA (docbook, etc) get updated for the features?
>>>
>>> I did a search on type expression and didn't find any mention of the new dot
>>> notation, for example.
>>>
>>> Cheers. -Marshall
>>>
>>> On 11/15/2019 11:49 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> the first release candidate of Apache UIMA Ruta v2.8.0 is ready for voting.
>>>> This minor release is not compatible with UIMA v3
>>>>
>>>> Major changes in this release:
>>>>
>>>> UIMA Ruta Language and Analysis Engine:
>>>>     
>>>> - The analysis engine is able to generate debug information about
>>>> inlined rules which includes also an extension of the ruta type system.
>>>> - Type expressions in dot notation for annotation expressions a new
>>>> supported: a1:ANY a2:ANY{a1.type==a2.type -> Type};
>>>> - Matching on string literals is no more restricted to single RutaBasic
>>>> annotations, e.g., it is not possible to write: "This is a test"{-> Test};
>>>> - Dictionary matching is now more robust concerning white spaces in the
>>>> word list. The parameter dictRemoveWS is now also set to true by default.
>>>> - Fixed anchors at composed rule elements.
>>>> - Labels at macro actions are supported now.
>>>> - Fixed several bugs.
>>>>
>>>> UIMA Ruta Workbench:
>>>>
>>>> - New view for visualizing the explanation of inlined rules.
>>>> - Fixed problem with blocked build processes in Ruta projects with many
>>>> scripts.
>>>> - Fixed bugs.
>>>>
>>>>
>>>>
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/orgapacheuima-1239/
>>>>
>>>> SVN tag:
>>>> https://svn.apache.org/repos/asf/uima/ruta/tags/ruta-2.8.0
>>>>
>>>> Update site:
>>>> https://dist.apache.org/repos/dist/dev/uima/ruta/ruta-2.8.0-rc1/eclipse-update-site/ruta/
>>>>
>>>> Archive with all sources:
>>>> https://dist.apache.org/repos/dist/dev/uima/ruta/ruta-2.8.0-rc1/ruta-2.8.0-source-release.zip
>>>>
>>>> Overall 33 issues have been fixed for this release (2 with other resolution)
>>>> They can be found in the RELEASE_NOTES.html.
>>>>
>>>> ... and here:
>>>>
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.8.0ruta%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>>>
>>>> Please vote on release:
>>>>
>>>> [ ] +1 OK to release
>>>> [ ]  0 Don't care
>>>> [ ] -1 Not OK to release, because ...
>>>>
>>>> Thanks.
>>>>
>>>> Peter
>>>>

Re: Thinking about release candidates

Posted by Marshall Schor <ms...@schor.com>.
:-) -Marshall

Re: Thinking about release candidates

Posted by Peter Klügl <pe...@averbis.com>.
Hi,


I finally applied a simple and reliable rule of thumb: If you think too
much about preparing another RC, stop and just do prepare it. Never
failed me.


Best,


Peter


Am 20.11.2019 um 16:01 schrieb Marshall Schor:
> Hi,
>
> Here's how I think about releasing vs doing another RC:
>
> 1) any release we put out will be defective (in some ways), because we're
> releasing complicated things.
>
> 2) The question about whether to release or not, therefore, doesn't depend on
> not finding issues.
>
> 3) The release question becomes, then, is it better for the community to have
> this out (now), versus waiting a bit for a few more fixes/improvements?
>
> It seems that this last question has to juggle conflicting goals / issues, such as
>
> a) users want the fixes improvements, sooner than later (but if by later, we
> mean a delay of a few days, probably doesn't matter)
>
> b) users don't like to upgrade - it's potentially destabilizing, and "busy work"
> usually.  So "bothering" our users with excessive upgrades isn't so good. 
> Example: the new Java release system, where there's 1 long-term-stable release
> followed by 2 short releases; I think most people don't bother with the short
> term releases...
>
> c) overall quality impression: we want our users to continue to feel their use
> of our systems is "investible", that is they can invest their time and energy in
> using these, with an expected level of quality - that the systems can be relied
> on to deliver their promises.  Part of quality is the documentation, and how
> "consumable" things are (this word encompasses many things, often around
> concepts of how easy is it to climb the learning curve).  If the quality
> impression drops, that could be a reason to do another RC.
>
> Sorry if this is all completely obvious - I thought it might be worth saying :-)
>
> -Marshall
>
> On 11/19/2019 7:30 AM, Peter Klügl wrote:
>> Hi,
>>
>>
>> I have been thinking a lot about it since your mail and I was not yet
>> able to decide about a new RC. Don't misunderstand me, there should of
>> course be a new RC. Here's why I did not yet cancel the current RC:
>>
>>
>> There was the new functionality for the explanation (debug info) of
>> inlined rules, which is described in the two new paragraphs. I did not
>> add a screenshot because I want to use it in practice before I decide
>> where to put it in the perspective.
>>
>> The dictionary changes can be viewed as bug fixes since they adapt the
>> default behavior to be more compatible with the users. Same is true for
>> the improved literal string matches and the labels at macro action:
>> (many) users thought it should behave in a certain way and thought they
>> found a bug. So, I did not change the docs for it.
>>
>> The fact that I forgot about the type expression is really annoying.
>>
>>
>> So I would mainly extend the syntax description for the type and add an
>> example in the new RC.
>>
>>
>> And here's the thing why I hesitate: The next thing I do is prepare an
>> RC for Ruta 3.0.0, which will replace the current documentation which
>> most users will look at. I assume that the extended documentation in
>> 2.8.0 will hardly be read by anyone...
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>> Am 18.11.2019 um 19:53 schrieb Marshall Schor:
>>> I looked at the svn change log since 2.7.0 was released (24 Feb 2019), and see
>>> only one change: adding 2 paragraphs for Inlined Rules.
>>>
>>> So I don't think there is any doc about the new debug info for inlined rules, or
>>> the enhanced Dictionary Matching, or the new default setting for dictRemoveWS,
>>> or new support for labels at macro actions.
>>>
>>> I'll leave it up to you, but it seems to me that it would be worth another RC to
>>> get the new stuff documented, into both the docbook and (also maybe?) any JavaDocs.
>>>
>>> -Marshall
>>>
>>>
>>> On 11/18/2019 12:11 PM, Marshall Schor wrote:
>>>> Hi,
>>>>
>>>> Did the documentation for RUTA (docbook, etc) get updated for the features?
>>>>
>>>> I did a search on type expression and didn't find any mention of the new dot
>>>> notation, for example.
>>>>
>>>> Cheers. -Marshall
>>>>
>>>> On 11/15/2019 11:49 AM, Peter Klügl wrote:
>>>>> Hi,
>>>>>
>>>>> the first release candidate of Apache UIMA Ruta v2.8.0 is ready for voting.
>>>>> This minor release is not compatible with UIMA v3
>>>>>
>>>>> Major changes in this release:
>>>>>
>>>>> UIMA Ruta Language and Analysis Engine:
>>>>>     
>>>>> - The analysis engine is able to generate debug information about
>>>>> inlined rules which includes also an extension of the ruta type system.
>>>>> - Type expressions in dot notation for annotation expressions a new
>>>>> supported: a1:ANY a2:ANY{a1.type==a2.type -> Type};
>>>>> - Matching on string literals is no more restricted to single RutaBasic
>>>>> annotations, e.g., it is not possible to write: "This is a test"{-> Test};
>>>>> - Dictionary matching is now more robust concerning white spaces in the
>>>>> word list. The parameter dictRemoveWS is now also set to true by default.
>>>>> - Fixed anchors at composed rule elements.
>>>>> - Labels at macro actions are supported now.
>>>>> - Fixed several bugs.
>>>>>
>>>>> UIMA Ruta Workbench:
>>>>>
>>>>> - New view for visualizing the explanation of inlined rules.
>>>>> - Fixed problem with blocked build processes in Ruta projects with many
>>>>> scripts.
>>>>> - Fixed bugs.
>>>>>
>>>>>
>>>>>
>>>>> Staging repository:
>>>>> https://repository.apache.org/content/repositories/orgapacheuima-1239/
>>>>>
>>>>> SVN tag:
>>>>> https://svn.apache.org/repos/asf/uima/ruta/tags/ruta-2.8.0
>>>>>
>>>>> Update site:
>>>>> https://dist.apache.org/repos/dist/dev/uima/ruta/ruta-2.8.0-rc1/eclipse-update-site/ruta/
>>>>>
>>>>> Archive with all sources:
>>>>> https://dist.apache.org/repos/dist/dev/uima/ruta/ruta-2.8.0-rc1/ruta-2.8.0-source-release.zip
>>>>>
>>>>> Overall 33 issues have been fixed for this release (2 with other resolution)
>>>>> They can be found in the RELEASE_NOTES.html.
>>>>>
>>>>> ... and here:
>>>>>
>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.8.0ruta%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>>>>
>>>>> Please vote on release:
>>>>>
>>>>> [ ] +1 OK to release
>>>>> [ ]  0 Don't care
>>>>> [ ] -1 Not OK to release, because ...
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Peter
>>>>>
-- 
Dr. Peter Klügl
R&D Text Mining/Machine Learning

Averbis GmbH
Salzstr. 15
79098 Freiburg
Germany

Fon: +49 761 708 394 0
Fax: +49 761 708 394 10
Email: peter.kluegl@averbis.com
Web: https://averbis.com

Headquarters: Freiburg im Breisgau
Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó

Re: Thinking about release candidates

Posted by Peter Klügl <pe...@averbis.com>.
I just wanted to add that I agree with all of the points in both of your
emails :-)


Peter


Am 20.11.2019 um 17:03 schrieb Richard Eckart de Castilho:
> On 20. Nov 2019, at 16:01, Marshall Schor <ms...@schor.com> wrote:
>> b) users don't like to upgrade - it's potentially destabilizing, and "busy work"
>> usually.  So "bothering" our users with excessive upgrades isn't so good. 
>> Example: the new Java release system, where there's 1 long-term-stable release
>> followed by 2 short releases; I think most people don't bother with the short
>> term releases...
> It is true that users usually do not like to upgrade, but that doesn't mean
> not to make release, does it? After all, they can decide if they want to upgrade
> or not. And I think it is good to make releases rather often for various reasons:
>
> - the more often you make a release, the more you care to make it a convenient
>   process (i.e. automatize as much as possible); the less mistakes you make during
>   a release; the less you have to review, etc.
>
> - those users who are waiting for a particular fix can get it quickly without having
>   to work with SNAPSHOT builds
>
> - contributions can make it to a release more quickly which makes it more attractive for
>   people to contribute
>
> - it underlines the activity of the project
>
> - actually the "upgrade risk" gets smaller because there are less potentially problematic
>   changes between each release - and because of early adopters' feedback, you might be able
>   to fix many of these problems before they even impact on the bulk of the users, simply by
>   putting out another release which circumvents the problem
>
> So, if somebody would ask me to go for few and big releases vs. small incremental and frequent
> released, I'd go for the latter. 
>
> But I also usually work with a development branch (preparing new feature for the next "big"
> release) and a maintenance branch (bug fixes and small improvements for the last "big" release)
> I feel which is necessary ask an additional means of balancing upgrade risks vs. development
> speed vs. bug-fixing speed.
>
> In my "fastest moving" project right now, we have bugfix releases every 2-3 weeks and feature
> releases every 6-8 weeks.
>
> Cheers,
>
> -- Richard

-- 
Dr. Peter Klügl
R&D Text Mining/Machine Learning

Averbis GmbH
Salzstr. 15
79098 Freiburg
Germany

Fon: +49 761 708 394 0
Fax: +49 761 708 394 10
Email: peter.kluegl@averbis.com
Web: https://averbis.com

Headquarters: Freiburg im Breisgau
Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó

Re: Thinking about release candidates

Posted by Richard Eckart de Castilho <re...@apache.org>.
On 20. Nov 2019, at 16:01, Marshall Schor <ms...@schor.com> wrote:
> 
> b) users don't like to upgrade - it's potentially destabilizing, and "busy work"
> usually.  So "bothering" our users with excessive upgrades isn't so good. 
> Example: the new Java release system, where there's 1 long-term-stable release
> followed by 2 short releases; I think most people don't bother with the short
> term releases...

It is true that users usually do not like to upgrade, but that doesn't mean
not to make release, does it? After all, they can decide if they want to upgrade
or not. And I think it is good to make releases rather often for various reasons:

- the more often you make a release, the more you care to make it a convenient
  process (i.e. automatize as much as possible); the less mistakes you make during
  a release; the less you have to review, etc.

- those users who are waiting for a particular fix can get it quickly without having
  to work with SNAPSHOT builds

- contributions can make it to a release more quickly which makes it more attractive for
  people to contribute

- it underlines the activity of the project

- actually the "upgrade risk" gets smaller because there are less potentially problematic
  changes between each release - and because of early adopters' feedback, you might be able
  to fix many of these problems before they even impact on the bulk of the users, simply by
  putting out another release which circumvents the problem

So, if somebody would ask me to go for few and big releases vs. small incremental and frequent
released, I'd go for the latter. 

But I also usually work with a development branch (preparing new feature for the next "big"
release) and a maintenance branch (bug fixes and small improvements for the last "big" release)
I feel which is necessary ask an additional means of balancing upgrade risks vs. development
speed vs. bug-fixing speed.

In my "fastest moving" project right now, we have bugfix releases every 2-3 weeks and feature
releases every 6-8 weeks.

Cheers,

-- Richard