Planning a release?

[mohataher]

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]

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]

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.
2. 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]

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]

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]

Great description, thank you.

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

[mohataher]

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

[patrickzib]

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

I have changed the groupId accordingly.

[mohataher]

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]

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]

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]

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.