Semantic versioning

[LFDM]

It's time to start thinking about real semantic versioning and real release cycles.

I still want to release frequently to fix occassional bugs - right now it's all uncontrolled though.

Weekly iterations for patches might actually work - this would also allow us to use real milestones and organize the chaos a bit.

[LFDM]

It might be beneficial if we setup a second instance of Arethusa on a sosol server. A bleeding edge version, where we can ask users for feedback on new features and can test them to have some insurance that they don't break the main deployed version.

@balmas, what do you think?

[balmas]

I support this idea. Need to think a little about the best way to access it through Perseids.

[balmas]

Related, am wondering about release of Arethusa and instructions for working in a standalone mode without Perseids...

[LFDM]

The guide describes a scenario where you don't use Perseids, but a local server.

Best way to access the staging environment: Arethusa could maybe support this on it's own - could add an additional button to the navbar maybe - but that's not really ideal either.

[balmas]

Let's think about the staging environment a bit.

[LFDM]

Sure, it's late enough to call it a day anyway :)

[balmas]

What do you think about this? Tools can be configured with A/B urls on Perseids and I can add the ability for a user to choose which they want to use and store this in a cookie. Perseids will check the user's cookie to decide which link to present to the user for each tool.

[LFDM]

I like it.

[balmas]

You know, could we also use this means to store user global settings prefs while waiting for an independent user model? I could add support to the Perseids API for setting user prefs which just stored a browser cookie, and arethusa could use that to persist global settings changes