Update MerlinAU.sh Backupmon Versioning Update

[ExtremeFiretop]

1. Remove the migrate settings function.
   It's served it's purpose. It's been around since the pre-release version of 0.2.54 and we are now on 1.0.3 and going to 1.0.4, that means it's been in the script for at least 5 version cycles. (0.2.54 --> 1.0.0 --> 1.0.1 --> 1.0.2 --> 1.0.3)

2. Upped BACKUPMON minimum version
   Increased the minimum version to the current of 1.5.3 using the new version standard going forwards. Considering he said in the forums him and thelonelycoder are also using this new standard going forwards, I figured it's best we up the minimum, should be one of the last times we need to do it.

3. Added a method for the script to still process the older versions such as 1.46 and 1.44 standards for comparison and treat them as lower.

[ExtremeFiretop]

@Martinski4GitHub

I actually just realized the last time we modified the migrate settings function was Jan 30th in version: 1.0.1
So it's still been in the script in its current form for at least 3 cycles, and an additional 2 cycles in a simpler form.

Considering it's only 3 cycles I'm open to leaving it in if you have a preference.
Let me know, I can easily commit it back in before we merge :)

[Martinski4GitHub]

@Martinski4GitHub

I actually just realized the last time we modified the migrate settings function was Jan 30th in version: 1.0.1 So it's still been in the script in its current form for at least 3 cycles, and an additional 2 cycles in a simpler form.

Considering it's only 3 cycles I'm open to leaving it in if you have a preference. Let me know, I can easily commit it back in before we merge :)

I'd say leave the code for one more release cycle. It doesn't hurt since it's a simple check, IMO.

[ExtremeFiretop]

@Martinski4GitHub
I actually just realized the last time we modified the migrate settings function was Jan 30th in version: 1.0.1 So it's still been in the script in its current form for at least 3 cycles, and an additional 2 cycles in a simpler form.
Considering it's only 3 cycles I'm open to leaving it in if you have a preference. Let me know, I can easily commit it back in before we merge :)

I'd say leave the code for one more release cycle. It doesn't hurt since it's a simple check, IMO.

Agreed, I had a crazy day but today while I was out shopping with the girlfriend, she was trying clothes on and all I was thinking about was if this is safe to remove yet lol.

My conclusion is maybe someone installed our re-release and took a month long vacation, we haven't been a full month since the last time we touched it in 1.0.1 and so it's just safer to leave it than to take it out.

[ExtremeFiretop]

No harm in leaving, still a small chance of potential harm to remove it.
So lets keep it in :) BRB! Back at my desk finally to commit it back in.

[ExtremeFiretop]

@Martinski4GitHub

Done. Looks right to me :) Feel free to review and merge when ready!

[Martinski4GitHub]

My conclusion is maybe someone installed our re-release and took a month long vacation, we haven't been a full month since the last time we touched it in 1.0.1 and so it's just safer to leave it than to take it out.

Yes, exactly. The latest code hasn't been there long enough to allow all users to update, especially since this is not the kind of script that people run frequently in an interactive session. So for those month-long stragglers :>), let's give them more time to catch up.

[ExtremeFiretop]

@Martinski4GitHub

Are we pretty much done/ready for the next major release or did you have any other last minute thoughts of things to add/change?

I figured will have to do a small "maintenance" release after the next firmware drop to up the minimum firmware version supported.

We can always re-assess the removal of the migration function in a maintenance release in the future.

[Martinski4GitHub]

@Martinski4GitHub

Are we pretty much done/ready for the next major release or did you have any other last minute thoughts of things to add/change?

Sorry, my brother stopped by & we're going out for dinner soon.

Just quickly, he also likes the new feature of having a CC option for email notifications; but he also proposed to add an option to set the email format type to either "HTML" or "Plain Text."

The reason is two-fold: a) It gives users an "out" if their specific email server appears to mangle the emails being sent in HTML format, and b) If a user chooses to add the email address from the cellular carrier (e.g. T-Mobile, Verizon) to get SMS notifications, the "Plain Text" format would be the preferred choice.

I like his reasoning so I'm thinking of adding a menu option for that. What do you think?
There's no rush for it, so we could release what we have now, and add the new option for the next version.

BTW, I was planning to make some minor changes to the email code (15 minutes tops with testing). I can do it after we come back from dinner.

Talk to you later.

[ExtremeFiretop]

@Martinski4GitHub
Are we pretty much done/ready for the next major release or did you have any other last minute thoughts of things to add/change?

Sorry, my brother stopped by & we're going out for dinner soon.

Just quickly, he also likes the new feature of having a CC option for email notifications; but he also proposed to add an option to set the email format type to either "HTML" or "Plain Text."

The reason is two-fold: a) It gives users an "out" if their specific email server appears to mangle the emails being sent in HTML format, and b) If a user chooses to add the email address from the cellular carrier (e.g. T-Mobile, Verizon) to get SMS notifications, the "Plain Text" format would be the preferred choice.

I like his reasoning so I'm thinking of adding a menu option for that. What do you think? There's no rush for it, so we could release what we have now, and add the new option for the next version.

BTW, I was planning to make some minor changes to the email code (15 minutes tops with testing). I can do it after we come back from dinner.

Talk to you later.

No worries buddy enjoy dinner!
My girlfriend is actually just making dinner for us now.

(Yes it's 11pm and it's later than usual for us, but like I said it's been a crazy day!)

I actually like the idea too. But take your time, I mean like you said this current solution we have we can expect to work for most major mail servers in north America, but your point and his point still stands that there can be a specific provider we don't account for, etc. and we should give those specific exceptions a way out.

It's one of those services that it's hard to account for all the variables and variations out in the world.

[Martinski4GitHub]

No worries buddy enjoy dinner! My girlfriend is actually just making dinner for us now.

(Yes it's 11pm and it's later than usual for us, but like I said it's been a crazy day!)

We've been known to have late dinners ourselves; 9:00 pm is fairly common, and on the weekends it could be around 11:00 pm while watching a couple of movies.

I actually like the idea too. But take your time, I mean like you said this current solution we have we can expect to work for most major mail servers in north America, but your point and his point still stands that there can be a specific provider we don't account for, etc. and we should give those specific exceptions a way out.

It's one of those services that it's hard to account for all the variables and variations out in the world.

Yes, exactly. Having both format options at the control of the user would help in those unknown situations.