+1 in making sure the commit message is just what you need.
The less a contributor needs to worry the better (automating the process
for the changes will reduce mistakes)
In regards to Jira, we are already coupled with Jira through the Issue key
in the commit and in the changes entry,
so I am not
I think the goal would be to minimize this editing, instead, try to
improve/standardize formatting of commit messages to do whatever you
need.
You can get some ideas from other projects doing it this way:
Linux kernel:
* detailed changelog:
Nice idea Rob... I like it! I didn't know other projects typically do it
this way.
I suppose the release process would involve a manual collaborative editing
period of the generated change files, perhaps facilitated by the Confluence
wiki where we could clean up the raw output. Or maybe create
git-log is better than JIRA for this. A lot of projects generate
release notes from it.
here's a dirty stab at LUCENE 8.6.2 release notes looking similar to
CHANGES.txt: git log --format=format:"* %s%n%b (%an)%n" --grep
"^LUCENE" releases/lucene-solr/8.6.1..releases/lucene-solr/8.6.2
-
*
Couldn't help pitching in here and making a humble request. The CHANGES.txt
has been of immense help for us for determining the right upgrade version
for our production deployments. So CHANGES.txt or no CHANGES.txt, I hope
we'll retain a mechanism to clearly be able to track the changes in
I get your point on different audiences... sometimes I peer-review us on
dubiously written CHANGES.txt entries to be more user friendly. However,
this attention could and should be given to JIRA issue summaries as well.
We all benefit from that. Also, for Solr in particular, the need for
I have a preference for maintaining a separate CHANGES file because it
allows us to keep JIRA focused for a committer/contributor audience while
the CHANGES file can describe changes that matter for users. Elasticsearch
uses a similar mechanism for release notes to what you are proposing, using
Well the commit history remains there as well and was converted from SVN
and may eventually be converted to something else. My point is that it has
been retained. On release boundaries, we could not only distribute
Changes.html (a JIRA export) in the assembly (tar.gz) but we could also
commit it
Changes in the repository stay there forever (think
cvs/svn/git/whatever comes next...). External tools change all the
time. This is the benefit I see.
Dawid
On Sun, Nov 29, 2020 at 6:32 AM David Smiley wrote:
>
> After recently proposing per-module CHANGES.md... I think I'd actually rather
>
Here's a link that might be added to the prometheus contrib README:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20component%20%3D%20%22contrib%20-%20prometheus-exporter%22%20AND%20resolution%20%3D%20Fixed%20ORDER%20BY%20fixVersion%20DESC%2C%20issuetype%2C%20priority
The
It is a kind of a side note, but server-based Jira product is going away
soon-ish.
I hope somebody at Apache has a plan forward. Especially since cloud Jira
is apparently much worse right now.
Regards,
Alex
On Sun., Nov. 29, 2020, 12:32 a.m. David Smiley, wrote:
> After recently proposing
After recently proposing per-module CHANGES.md... I think I'd actually
rather not have any CHANGES file at all to maintain. I'd rather go to JIRA
with a bit better hygiene for metadata like components==contrib/module, and
have some convenient links sprinkled about so that it's a convenient click
12 matches
Mail list logo
