SRL Archive - General News

Hi,

We've been pretty anxious to make a release of Simba for a while (or a Release Candidate) but we're not quite sure if Simba would be ready for the masses. (There's my first question)

There are a few things we should do nevertheless; and that is creating some rules and guidelines as to how Simba release schedules are to be done.

Usually, projects follow a schedule like this:

Add lots of (unstable) code;
Release an alpha, fix some bugs;
Release a beta, feature freeze (no more stuff added); fix more bugs;
Release candidate, fix bugs;
Release;
Repeat.

I think it would be good to try and follow schedules a bit similar to this.

With Simba, we currently provide updates whenever we changed something and deem it ``safe'' for the users to try. At least, that's what we did in the BETA stage.

I think we can easily have two ``branches'' of Simba; stable and unstable. (I actually already set up http://simba.villavu.com/bin/ up for Stable and Unstable versions)

Simba users could then change the URL to their Simba binary and version to change to and from Stable/Unstable. The updater will take care of the rest.
How does that sound? (Second question)

~Wizz

I think it is ready for the masses, I don't see any reason it wouldn't be.

and I think that sounds good. :)

But I thought SRL followed that whole stable/unstable thing, and yet, everyone now uses the latest developer revision as the official releases are always behind.

If the "stable" Simba is consistently updated, then I suppose the two branch thing would work out. But if not, one product would be better.

From: Infantry001
But I thought SRL followed that whole stable/unstable thing, and yet, everyone now uses the latest developer revision as the official releases are always behind.

If the "stable" Simba is consistently updated, then I suppose the two branch thing would work out. But if not, one product would be better.

Unstable Simba would contain features that are not yet considered stable but do need testing. Stable Simba is what all the people who just want to run their macro would use. Once certain features are Stable, they will be merged into the Stable version of Simba, and the Stable version will be updated. Most likely there will be no differences between the Stable/Unstable versions of Simba for the actual SRL include. And if there will be, then a few defines will most likely take care of it. I do however think SRL itself should stick to one repository only, which should just consider commits that are done carefully and are brought straight to the end users. (So drop /srl, and use only /srl-opendev)

Rev 695 is REALLY good and stable imho. (cheers to the devs :) ) I think Stable/Dev version is fine for a public release for now. This way we start getting Simba used more and we can still test the new stuff until its ready (Script database, etc.).

Is Simba ready for the public? I'd have to say yeah! But how do you get it to the public? Like, what audience is going to get it that doesn't have it now?

If a feature is unstable, someone will just simply not use it, no? Or is it impossible to avoid that?

Thinking of functions for the MML, you could always add

T_FindColorsSuperSpiral

(T for test), to note it as an "experiment" function.

As for the script manager and so on, better have an unstable version than no version!

~RM

If you're going to have two versions you need a clear way of determining when a version is "stable". Otherwise you'll have something that resembles the two SRL repos where the "stable" version isn't even updated cos no one knows when a dev repos is stable.

I think releasing a stable and unstable to the public would create problems. I'm already confused about changing between the two and, undoubtedly, so will others be.
And as noted in posts above, the stable will not get developed because, well, it's stable!

Also, what's the difference between stable and unstable?
Unstable has some other code that stable doesn't have. Which means that people could use unstable and just not use the unstable functions, which would practically be the same as stable.

I say, release one kind: Unstable
If you put all your energy into fixing the bugs in unstable, it will have a better effect then half manpower on stable and half on unstable. And it would only get us half the new features you make up during the way.

tl;dr: Releasing two versions will be a mess.

I'd say have a Developer Channel for those who want to, but regularily produce stable builds.

I'd almost say that developer version could just be the git repos, and you can compile it yourself.

From: Rasta Magician
If a feature is unstable, someone will just simply not use it, no? Or is it impossible to avoid that?

Thinking of functions for the MML, you could always add

T_FindColorsSuperSpiral

(T for test), to note it as an "experiment" function.

As for the script manager and so on, better have an unstable version than no version!

~RM

I like this better than having two separate builds. It also helps you pinpoint bugs in new code easier (and faster), because I think the main part of the users will not use the developer build. I think the way it is now is good.

One version also solves lots of problems like, what code is in where etc. it's easier to get it organized.

I think there should only be one. That would stop the "Oh, get the unstable version of the repo for this script." Also, I know that a few people who don't develop will use the unstable version, and if they make a script, they might not be compatible with the stable version.

I dunno. To me it makes much more sense to just have one.

(There can be only one!)

From: ZephyrsFury
If you're going to have two versions you need a clear way of determining when a version is "stable". Otherwise you'll have something that resembles the two SRL repos where the "stable" version isn't even updated cos no one knows when a dev repos is stable.

This is not the same. The SRL releases are simply ill maintained.

The difference between Stable and Unstable is that some stuff in Unstable is much more prone to crashing. Simply using only the Stable branch and telling everyone not to use a specific feature sounds weird to say the least, IMO. I don't expect a program to include a feature that is known to be buggy in their stable version.

Let's say I wrote a new rs_getuptext, and I want people to test it out. What would I do? Update Stable Simba and hope it works for everyone? What if it doesn't work and crashes randomly? This will be a huge problem for end users.

If you want people to test Simba, it will have to be made easy. The unstable version will not be released, it will just be there for people who want to test Simba.

Really, they are just binary builds that include slightly different features… Stable will include all the stable features, Unstable will also merge in unstable features / branches. Stable is to be used by everyone who wants to macro, Unstable is for the people who like to try bleeding edge software.

Obviously scripts should refrain from using features from the unstable Simba. They can use the features to test it, but they should not force users to switch to unstable Simba. It shouldn't be much of a problem because as soon as scripts start using those features, they will probably be declared stable soon, and merged into Stable Simba.

Just my view…

PS: One branch is fine too, I guess. Just not as end-user friendly.

From: Wizzup?
This is not the same. The SRL releases are simply ill maintained.

The difference between Stable and Unstable is that some stuff in Unstable is much more prone to crashing. Simply using only the Stable branch and telling everyone not to use a specific feature sounds weird to say the least, IMO. I don't expect a program to include a feature that is known to be buggy in their stable version.

Let's say I wrote a new rs_getuptext, and I want people to test it out. What would I do? Update Stable Simba and hope it works for everyone? What if it doesn't work and crashes randomly? This will be a huge problem for end users.

If you want people to test Simba, it will have to be made easy. The unstable version will not be released, it will just be there for people who want to test Simba.

Really, they are just binary builds that include slightly different features… Stable will include all the stable features, Unstable will also merge in unstable features / branches. Stable is to be used by everyone who wants to macro, Unstable is for the people who like to try bleeding edge software.

Obviously scripts should refrain from using features from the unstable Simba. They can use the features to test it, but they should not force users to switch to unstable Simba. It shouldn't be much of a problem because as soon as scripts start using those features, they will probably be declared stable soon, and merged into Stable Simba.

Just my view…

PS: One branch is fine too, I guess. Just not as end-user friendly.

I see no problem really with having 2 branches assuming it is used how you describe it here. Having everyone except people who want to test refrain from using the unstable version etc.

I would go for 2 branches.. "Huge" things that are to be added to Simba can be tested easier this way.

And give meaningful names to stuff and try to split it up a bit.