patrickzib / SFA

Scalable Time Series Data Analytics
GNU General Public License v3.0
311 stars 67 forks source link

Planning a release? #18

Open mohataher opened 6 years ago

mohataher commented 6 years ago

Hi Patrick:

Great effort has been put into this library later. Such a great work. Do you have any plans for a v0.1 version release?

We should also aim at uploading that release's artifact to the Maven's central repository. This will make it easier for new comers to use it in their projects and give the library an industrial legitmacy.

patrickzib commented 6 years ago

That sounds like a good idea! I am fine with a v0.1 release. There is currently nothing missing that I could think of.

Do you have any experience with uploading to the Maven central repository? I did a quick search and it sounds like Sonatype OSSRH is the way to go?

mohataher commented 6 years ago

Great. Yes, that's the way to go. I'm happy to help. Here's a quick look at the required info and what I think should go there. Please review.

Summary: Scalable Time Series Data Analytics Description: This repository contains a symbolic time series representation (SFA) and three univariate (WEASEL, BOSS and BOSSVS) and one multivariate (WEASEL+MUSE) time series model(s) for alignment-free, noise-robust and scalable time series data analytics.

The implemented algorithms are in the context of:

  1. Dimensionality Reduction: SFA performs significantly better than many other dimensionality reduction techniques including those techniques based on mean values like SAX, PLA, PAA, or APCA. This is due the fact, that SFA builds upon DFT, which is significantly more accurate than the other dimensionality reduction techniques.
    1. Classification and Accuracy: WEASEL and the BOSS ensemble classifier offer state of art classification accuracy.

Project URL: https://github.com/patrickzib/SFA Group ID: MISSING!!! SCM url: https://github.com/patrickzib/SFA Username/s: Would you like me to help here? I can add my username mohataher to help in deployment. I will need your JIRA username as well. Already synced to Central: NO

We are missing Group ID. It seems like build.gradle is missing one. I will send you a PR shortly. Please test it before you merge.

mohataher commented 6 years ago

Just added Group ID and Artifact ID as sfa. That is due to the fact that group IDs and Artifact IDs have to match with the package naming.

I don't really like sfa as group and artifact IDs. But if we want something better, we need to rename sfa package to something more appropriate. more info

patrickzib commented 6 years ago

Thank you. I agree that the naming sfa is not perfect. This was the first publication on which the others are based on, but it does not reflect the whole anymore. I am not too sure about renaming the whole package structure though, as this will cause the history to be lost (we had that when we moved to gradle, too).

patrickzib commented 6 years ago

Great description, thank you.

Sure, I am glad for any help! My JIRA username is patrick.schaefer

mohataher commented 6 years ago

Just submitted the application. Please check it out (and vote) https://issues.sonatype.org/browse/OSSRH-37346

patrickzib commented 6 years ago

It seems like the groupId has to be:com.github.patrickzib?

I have changed the groupId accordingly.

mohataher commented 6 years ago

That is a good start. It's highly recommended to change the package name to com.github.patrickzib.sfa. Let me see if I can do it without necessarily losing history of all files.

patrickzib commented 6 years ago

there might be another way. I spoke to a colleague and it is possible to use github to host an own maven repository: LINK

So, one option is: not to host on maven central but on github, and one can still add it to a maven pom...

<repository>
        <id>YOUR-PROJECT-NAME-mvn-repo</id>
        <url>https://raw.github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/mvn-repo/</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
</repository>

This link also mentions another two options: JitPack or BinTray...

patrickzib commented 6 years ago

until we figured out maven central and sonatype: I did add JitPack information for building the project on the readme. what do you think?

mohataher commented 6 years ago

I feel my thoughts here as I opened this issue were a bit foggy. Now I realise that we should have a process in place to release stable version of the library. This means making a release on the master branch (say v1). Then move any kind of new improvements, bug fixes to dev branch. Then eventually merge with master and release a new version (say v1.0.1).

With a release, we have to update documentation, how to use, provide examples, etc. It's not simple step but maybe necessary for mass adoption of the library.

When this system is in place, going to Central Repo would be a natural next step.

Currently I use JitPack and it works just fine with my public and private repos. Having the library on Central Repo adds legitimacy and easiness to developers.