Release to Maven Central

[vlsi]

Having a library at central would simplify parsing/analysis of the hpl files from other applications.

[nitsanw]

@RichardWarburton if you want to outline some pre-requisite tasks to release I can try and help out.

[RichardWarburton]

I wouldn't want to release anything until the log file format is properly stabilised.

I think the main thing is actually fixing #106 tbh. We should probably also add versioning to the log file format.

[vlsi]

What's the problem with releasing "as is", and improving the format later?

Alternative options are:

1. pulling hpl parser to one's own codebase
2. forking honest-profiler & releasing it

Both look worse than having a honest-profiler release.

[nitsanw]

@vlsi I think log format version is important (and easy to add), but otherwise agree

[RichardWarburton]

Good question! Unversioned file formats are basically a terrible mess, that lead to confusion. I have no idea why I didn't version the format to begin with. I don't want to release without versioning. This is probably not too much work though, would happily accept a patch if someone will volunteer one.

You're right that the current options are unappealing though. I guess the issue of making the file format more reliable can be deferred. Would be an easy change to make if we had versioning.

[vlsi]

For "future compatibility" one can just use magic number in a file header.
That way a proper file format can be implemented in a timely manner:

1. "old format" (the one without magic number) does not get changed
2. "new format" (the one with versions, etc, etc) can be planned with no hurry

If one just adds version prefix, that will make previous files unreadable.

nitsanw> I think log format version is important (and easy to add)

It is important. However, I think "absence of magic header and absence of version" qualifies as "version 0" of the file format. Future versions could either ignore "old format", or they could fall-back to this old format parser in case header is missing. That is exactly the same processing you'd end up with in case you do have different version numbers in the header.

Being able to release could even attract developers/users.

[nitsanw]

Recording from offline conversation:

• As a first step towards release it would be good to tackle outstanding mega PR Many new functions for the Profiler JavaFX UI #173
• Modularize build/code as per Modularise the build #65

At this point I suggest we consider a tag as an easy primitive release if dealing with a full on maven central release is considered too heavy weight.

[PhRX]

In the meantime I've added new features on the integration branch on my fork (by branching then merging, to somewhat separate the various features and fixes). If nobody has started reviewing #173, wouldn't it make sense to merge integration into the PR ? If anything, there's more documentation, and the code should have become cleaner and clearer. On the minus side, yes, there's even more of it.

[nitsanw]

@PhRX please continue discussion on relevant ticket

[PhRX]

@nitsanw Sorry, done. I considered it relevant as it might affect exactly what is being released, given a number of fixes on the integration branch which are important for the master (== PR) branch.