incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <>
Subject Re: retiring the changelog file
Date Tue, 29 Jan 2013 07:34:37 GMT
Hi Glen,

thanks for pointing out - I'm old-fashioned and magnetic tapes were 
highly fashionable and punch cards still in use when I started coding 
... :-).

Going back to the discussion - let's avoid mixing up intention and 
tools. My intention is visibility of a casual committer who only adds 
one or two bug fixes and I have the habit of honoring this small 
contribution in changes.xml since it becomes part of the site. I don't 
care how it's done ... ;-)


Siegfried Goeschl
Senile Software Engineer

On 29.01.13 03:10, Glen Mazza wrote:
> Oh--I haven't been bumping up the number because
> I was unaware that we needed to do that (Sorry, wasn't paying
> attention--I always wondered where that "2.9.1-svn-XX" value came from
> in the ChangeLog file...  :)  Now if I understand correctly, I *don't*
> need to bump up that number and update the ChangeLog file with trivial
> commits such as typos being fixed or should I be doing that for every
> commit?  I'm flexible here--I just need to know what to do.  (Once we
> Mavenize, incidentally, the manual incrementing numbering system might
> no longer be needed because somehow the Jenkins/Maven combination
> automatically generates snapshot bundles every day with something like a
> YYYYMMDDHH24MISS format appended to the name of the generated
> JARs/WARs.--I'm unsure here though.)
> Earlier today I asked two of my coworkers, Dan Kulp and Olivier Lamy,
> who are each committers on approximately 10 Apache projects each
> ( , users dkulp and olamy),
> how many of their projects use manually updated change files -- Dan
> reported zero and Olivier just one (Apache Commons, as Siegfried noted
> earlier).  So that's why I'm unaccustomed to maintaining such a
> file--I've never needed it and have never heard of people on these
> projects complaining about the lack of such a file.  (Incidentally, if
> we want to highlight contributors without a change file, we can always
> add them manually to our web site page, like Apache Camel does here:
> ) .
> One small concern to keep in mind about manually maintaining a change
> log, is that it may give an "old fashioned" image to the project,
> because such files were much more common 10-15 years ago before we had
> modern repository systems.  To the point that sleekness, coolness and
> modernity in a code base drive adoption (and more committers :),
> maintaining a change log file might be furthering an older image harming
> that goal.  (It would be perhaps akin to a teenage rockstar offering his
> music additionally on cassette and phonograph records, or Apple selling
> its MacBook Pro laptops with a 3 1/2-inch diskette drive slot. In both
> cases, you're harming the image of sleekness/modernity that drives a
> portion of sales.)  Just food for thought!
> Regards,
> Glen
> PS: Oh, to answer your question, sure, we can switch to an mdtext format
> as you propose; or switch our website to Commons Email style and just
> have it use the changes.xml directly (although I kind of like the softer
> format of our website compared to theirs -- especially since our website
> already looks much like JSPWiki :)
> On 01/28/2013 03:00 PM, Juan Pablo Santos Rodríguez wrote:
>> Hi,
>> the ChangeLog shows the lists of "versions", being a "version" something
>> similar to a (i.e.) Jenkins release (except that in Jenkins new release =
>> new war), that is, a bunch of new functionality, which may comprise
>> one or
>> several commits. In the latter case, the Changelog file comes in handy.
>> If a new functionality is added, the release number in
>> gets bumped and the ChangeLog file is updated
>> with
>> the appropiate info. Similarly a commit may not be itself worth a
>> "version", i.e.: a commit to omit some auto-generated files. What
>> constitutes a "version" and what not is left to the committer; as they're
>> cheap to generate it isn't a big deal.
>> Related to ChangeLog, and having mentioned Jenkins, I've just noticed
>> that
>> the ChangeLog file is very close to Markdown syntax, so we could use
>> it to
>> generate a $svn/site/trunk/content/jspwiki/development/changelog.mdtext
>> That would make the contributors' names a lot more visible.
>> A first step would have some kind of JUnit (or whatever), similar to
>> TranslationsCheck, to generate the appropiate file. Then this change
>> would
>> also be committed and then published (this could be done automatically
>> by a
>> Jenkins post-job @ builds.a.o). Hmmm and we could also refresh the
>> version
>> displayed @ i.a.o/jspwiki, and also publish another page with the
>> different
>> translation statuses..
>> thoughts?
>> br,
>> juan pablo
>> On Mon, Jan 28, 2013 at 3:16 AM, Ichiro Furusato
>> <>wrote:
>>> [-1]
>>> I'm not a committer so I don't get a vote, but FWIW I've always
>>> preferred
>>> human-managed change logs, since that means a human being is
>>> highlighting
>>> the more important changes, new or changed APIs, features, etc. whereas
>>> the machine-generated ones force me to slog through *all* of the
>>> changes.
>>> Yes, it does require some overhead but it's very helpful for
>>> co-developers.
>>> Ichiro
>>> On Sat, Jan 26, 2013 at 11:55 PM, Harry Metske <>
>>> wrote:
>>>> -0.5
>>>> I have always found this Changelog a very convenient mechanism of
>>> searching
>>>> for "what has changed when in what version".
>>>> You have it one file, easily searchable and scrollable.
>>>> The overhead is minimal, always cut/paste the Changelog update to the
>>>> commit log.
>>>> I agree that mentioned links provide all information (and more), but
>>>> not
>>> so
>>>> easy to search, you always have to click a hundred times before you
>>>> find
>>>> what you want.
>>>> kind regards,
>>>> Harry
>>>> On 25 January 2013 03:29, Glen Mazza <> wrote:
>>>>> Hi team, we have a "ChangeLog" file in the root folder that is
>>> apparently
>>>>> (?) updated whenever someone makes a commit.  I don't see a need
>>>>> for it,
>>>>> and none of the other Apache projects I'm aware of bothers with such
>>> file
>>>>> -- it's annoying needing to update it and it just seems to be
>>> unnecessary
>>>>> overhead.  Can we get rid of it?
>>>>> So long as you make comments when you commit, here is a 100.0%
>>>>> authoritative and chronological list of all commits made and what they
>>>>> involve:
>>>>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>>>>> jspwiki-commits/201301.mbox/**browser<
>>>>> And of course the SVN repository details the changes made to each
>>> specific
>>>>> file fully and accurately:
>>>>> webdocs/Error.jsp?view=log<
>>>>> Finally, JIRA nicely provides us a list of commits per release:
>>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<
>>>>> That should be good enough for us.  WDYT?
>>>>> Regards,
>>>>> Glen

View raw message