Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove build date support in favor of semantic versioning #148

Closed
balthisar opened this issue Feb 1, 2015 · 5 comments
Closed

Remove build date support in favor of semantic versioning #148

balthisar opened this issue Feb 1, 2015 · 5 comments
Milestone

Comments

@balthisar
Copy link
Member

Remove build date support in favor of versioning.

@balthisar balthisar added this to the 5.0.0 milestone Feb 1, 2015
@balthisar
Copy link
Member Author

I made the changes and pushed this. tidyReleaseDate() is marked in comments as deprecated which should be picked up by doxygen. I didn't include a compiler attribute to flag warnings in the interests of compatibility with non-GCC-style compilers.

Also reverted CMakeLists.txt and removed the date macro. version.h still supports the macro in case we want to revert this behavior, but I've set the default date to Unix epoch for lack of a better idea. People that are counting on tidyReleaseDate() should be able to see that something is wrong when they see the date.

An alternative would be to use tidyReleaseDate() as an alias for tidyLibraryVersion() but I don't know if any current users have a use case for parsing dates that might be broken by returning a version string instead of a formatted date.

Forgot to mention in the comments that I cleaned up some strings while I was at it to avoid mentions of "experimental" and "this fork", etc., as we near 5.0.0.

I'll leave this issue open for discussion re: what to return from tidyReleaseDate().

@balthisar
Copy link
Member Author

If no one cares what tidyReleaseDate() returns (currently Unix epoch), then I will assume everyone is satisfied and close this issue.

I'll leave it open for a few more days and cross-post to the three lists...

Oh, I suggest that we add a deprecated flag to tidyReleaseDate(). This is simple for GCC-like compilers, but I'm unfamiliar with other compilers -- is there a generally recognized, cross-compiler flag available for this?

@geoffmcl
Copy link
Contributor

@balthisar have never tried it myself but found this reference
http://stackoverflow.com/questions/295120/c-mark-as-deprecated

Will get around to trying it in MSVC and see what happens ;=))

#ifdef __GNUC__
#define DEPRECATED(func) func __attribute__ ((deprecated))
#elif defined(_MSC_VER)
#define DEPRECATED(func) __declspec(deprecated) func
#else
#pragma message("WARNING: You need to implement DEPRECATED for this compiler")
#define DEPRECATED(func) func
#endif
...
//don't use me any more
DEPRECATED(void OldFunc(int a, float b));
//use me instead
void NewFunc(int a, double b);

geoffmcl added a commit that referenced this issue Jun 9, 2015
There was an idea to mark this function deprecated, such that if used the
developer would see a warning. But this was never implemented in a cross
platform way.

So for now revert to circa Jan 2015 when Jim added a build date to the
version.txt file. And now both LIBTIDY_VERSION and RELEASE_DATE macros are
established in CMakeLists.txt, and picked up in version.h.

The idea is the date will now march forward with the version number, side
by side in version.txt. Although have left tidy.c only emitting the
version on the --version command.

After this function has been marked deprecated for several release periods,
only then should consideration be given to potentially removing it.
@geoffmcl
Copy link
Contributor

geoffmcl commented Jun 9, 2015

See Issue #190 for comments on why this reversion to continuing support for tidyReleaseDate()

@geoffmcl
Copy link
Contributor

For now continuing support for both version and date, although console tidy continues to only show only the version. Maybe the date could now also be added.

But no further comments for a few weeks so closing this for now...

Feel free to re-open, or post a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants