Propose CHANGES.txt releases begin with the categories (empty)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Propose CHANGES.txt releases begin with the categories (empty)

david.w.smiley@gmail.com
Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no "Improvements".... so no surprise here, the New Features category has issues that ought to be listed as such.  I think the order vary as well.  I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections.  They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty.  It seems addVersion.py is the code that sets this up.  Any opinions?

~ David Smiley
Apache Lucene/Solr Search Developer
Reply | Threaded
Open this post in threaded view
|

Re: Propose CHANGES.txt releases begin with the categories (empty)

Mikhail Khludnev-2
It's fine, David. 

On Tue, Jun 25, 2019 at 7:40 AM David Smiley <[hidden email]> wrote:
Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no "Improvements".... so no surprise here, the New Features category has issues that ought to be listed as such.  I think the order vary as well.  I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections.  They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty.  It seems addVersion.py is the code that sets this up.  Any opinions?

~ David Smiley
Apache Lucene/Solr Search Developer


--
Sincerely yours
Mikhail Khludnev
Reply | Threaded
Open this post in threaded view
|

Re: Propose CHANGES.txt releases begin with the categories (empty)

Adrien Grand
In reply to this post by david.w.smiley@gmail.com
+1, it's otherwise tempting to reuse an existing category even if it
doesn't fit as well as a category that is not listed yet.

On Tue, Jun 25, 2019 at 6:40 AM David Smiley <[hidden email]> wrote:
>
> Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no "Improvements".... so no surprise here, the New Features category has issues that ought to be listed as such.  I think the order vary as well.  I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections.  They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty.  It seems addVersion.py is the code that sets this up.  Any opinions?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley



--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose CHANGES.txt releases begin with the categories (empty)

Jan Høydahl / Cominvent
+1

PS: Check out the template in scripts/addVersion.py which now just adds "(no changes)"

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

25. jun. 2019 kl. 09:02 skrev Adrien Grand <[hidden email]>:

+1, it's otherwise tempting to reuse an existing category even if it
doesn't fit as well as a category that is not listed yet.

On Tue, Jun 25, 2019 at 6:40 AM David Smiley <[hidden email]> wrote:

Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no "Improvements".... so no surprise here, the New Features category has issues that ought to be listed as such.  I think the order vary as well.  I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections.  They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty.  It seems addVersion.py is the code that sets this up.  Any opinions?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley



--
Adrien

---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Propose CHANGES.txt releases begin with the categories (empty)

david.w.smiley@gmail.com

~ David Smiley
Apache Lucene/Solr Search Developer


On Tue, Jun 25, 2019 at 3:45 AM Jan Høydahl <[hidden email]> wrote:
+1

PS: Check out the template in scripts/addVersion.py which now just adds "(no changes)"

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

25. jun. 2019 kl. 09:02 skrev Adrien Grand <[hidden email]>:

+1, it's otherwise tempting to reuse an existing category even if it
doesn't fit as well as a category that is not listed yet.

On Tue, Jun 25, 2019 at 6:40 AM David Smiley <[hidden email]> wrote:

Looking at Solr's CHANGES.txt for 8.2 I see we have some sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  There is no "Improvements".... so no surprise here, the New Features category has issues that ought to be listed as such.  I think the order vary as well.  I propose that on new releases, the initial state of the next release in CHANGES.txt have these sections.  They can easily be removed at the upcoming release if there are no such sections, or they could stay as empty.  It seems addVersion.py is the code that sets this up.  Any opinions?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley



--
Adrien

---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]