This is most definitely something we believe is important to the future of rules development.  I do not yet have an ETA for when we'll deliver this critical functionality however it is very near the highest of user-submitted feedback.  I will absolutely keep this group posted as we make progress.

Jeremy Lahners anything you can share... I mean this has reached >40 votes.

Hey  ... can you give some insights, if you thing about implementing this?

Seems the community thinks its a good Idea.

KR

A

Hi Jeremy, 

the how... and what:

I think a version control of rules should store all actual rule filters, aggregaten settings, variables, etc.  

How many versions backwards... I think there should be somthing like a soft and a hard "definition of a new version" - so for example if you are developing a  rule, there might be a lot of changes, tweaking going on, before the rule is in a "version 1 state".  Therefore  you should have the choice to just save a rule (no new version is created), or save it as a new version - so a little bit like a commit in github. and why not put some possibility to put a comment. And for sure a rule gets saved as a new version, if there was no change after ~60 minutes or something like that. 

sure this will be get complicated, because auf dependencies... i.e. you have a "building-block" filter in a rule - should this filter be stored together with the version, or not - i would say no, as if you have code and use a library from "a third party" you dont store the complete library - however you might hava a note that it worked/tested/somthing like that, with this version of that filter.... so i think there should be something like a version warning or so. that keeps track with which version a rule was working with . However i think thats something MF as s software developing  house should have some experience with already.

I also think keeping only 2 version of a config is way to less, as a misthake normaly gets not spotted within one version. at least that's my experience - i would keep at least 5 versions - with the possibility of unlimited versions.

Having a "diff view" of rules/filters would be great - i think as a MVP beeing able to have one "editor window" with the latest version and another editor window with older versions would be already a very good enhancement. 

Deleting versions.... no not really -  as this would be against the "audit" principle that tha comes with this feature --- hence the unlimited storage for rules and filters.

Going back to a version... i would define it like use this "old version" as "new version"  - this makes easier to review and also for auditing purposes i would not just delete the versions that were created after the "old version".

I think both rules and filters should be treated in the text above internchangable...

I think thats already a lot of thoughts - if any questions, just come back and ask .

KR

A

Well, It's a very great idea to save time for lots of people. But, if it needs to keep old configuration, need to reduce maximum number of history&data. If not, it will make additional management point.

V.1.0 - just make the history of changes by whom
V.2.0 - Just keep 2 configurations for each version.