Preparing for new release

[adah1972]

I would like to do the following before the new release:

• Make Makefile.gcc and Makefile.msvc include grapheme break.
• Replace "@version" with "@date" (yeah, I've finally felt the version is more painful than useful), showing the last modification date.
• Update Doxyfile and check to ensure the documentation output is good.
• Update copyright headers to ensure the year 2016 is there.
• Change the version number to 4.0
• Change libtool version-info to 4:0:0. (Or do we want to use 4:0:1 so that old applications can use it as a drop-in replacement? It would be OK if applications did not use linebreakdef.h.)
• Update README and NEWS.
• Make a release.

Please check whether anything is incorrect or missing.

[tasn]

One comment before I begin: there's a way to mark a list as a task list in github, maybe consider doing that, so it's easier to follow what's done. :)

As for more specific comments:

1. I said it before in a private email, but let me say it again so it's documented on github: I don't see the value of tracking version and date manually. We have Git for that. When was the file last changed? "git log" will tell you that much better...
2. Copyright: I guess, if it's a legal requirement. In other projects I'm involved in we just have a centralised file to track copyright and etc so it's easier to update.
3. Libtool: it should be a drop-in replacement. You don't want to force people to recompile. Our ABI hasn't changed in a breaking way. Linebreakdef.h is undocumented API, people shouldn't be using it, and as I said before, I don't think we should even ship it. :)

[adah1972]

Oops, I missed the task list. I will use it next time.

1. I can clearly see the version outdated for files. Dates may potentially be useful for files out of version control... But you are probably right. The benefit seems too small.
2. I am not a lawyer, but I see many people track this in every file. Since it is not a big headache, I think I'll do it anyway.
3. OK, I'll use 4:0:1 then.

[adah1972]

BTW, I may do some reformatting, but won't do it fully automatically—doing so would unalign inline comments. Fully automatic formatting may still be useful in a big project, but I do not feel like doing so in this small project.

[adah1972]

I think I am done except the final release. Please help double-check the current status. If you do not see any problems, I'll make a new release.

[adah1972]

@tasn A few other minor things I would like to make about Doxyfile, unless you have objections:

• FULL_PATH_NAMES = NO. This gets rid of some noises.
• DOT_IMAGE_FORMAT = svg. This results in better images on high-resolution displays. It seems to work well with Safari, Firefox, and IE 10.
• SEARCHENGINE = YES. This allows searching in the HTML pages.

[adah1972]

To clarify, I would like to include the resulting documentation in the release. That means browsers not supporting SVG files will have trouble viewing the documentation.

[roever]

don't forget to document this "hidden" feature with the strict linebreaking of the japanese language. Right now it seems like it is only documenting that the language parameter contains the language.

And I also think that it would be nice to mention that the language is supposed to be an ISO 639-1 language code.

[tasn]

No objections, change them as you wish, all sound reasonable.

[adah1972]

I made some adjustments to the documentation comments, and made a test release at:

http://wyw.dcweb.cn/libunibreak-4.0.tar.gz

If you do not see any problems, I will add a tag to GitHub and make a formal release in three days.

[tasn]

Haven't tried your test release, but just pulled and ran make check for the last time. Everything still works.

I also ran the test apps with valgrind. Everything looks great.

[roever]

downloaded the archive and found one issue that needs fixing...

• make check doesn't run though, because the test_skips.h is missing

Additionally I do think that the doxygen documentation is not optimal. It contains much more information than required for a user. The user should only get the return enums and the 3 functions that create the breaking information for each breaking type... As it is it documents all these internals that are quite uninteresting for the user. When I started using the library I did use the c files and they did serve me well.... I don't know if it is intended the the doxygen documentation contains all that internal information?

[adah1972]

Good catch. src/Makefile.am is now updated.

As to the documentation, I do not think it necessary to remove existing documentation.... Users should normally only check *break.h, but not other files.

[adah1972]

Released.