Thanks @pdion891! I agree with all of them, except the systemvm template. There is no reason to bump that version because there is no change yet. As soon as we introduce a change that is not compatible with 4.6.0 template, we should bump the version. Until that happens, I'd like to be able to have 4.7.0 to use the same template as 4.6.0.

In the future we should get a separate systemvm version numbering schema (separate repo even?), to break with the "new cloudstack version == new systemvm version". Upgrades are much easier / less impacting if one does not need to recreate all sytemvms (1000+ in our case). Especially when we're releasing more often.

Pinging @DaanHoogland @bhaisaab to see what they think and if I maybe forget something? Can we keep the version of systemvms at 4.6.0 until something changes? If not, can we make it work?

@pdion891 See comments on https://issues.apache.org/jira/browse/CLOUDSTACK-9077 for possible solution for /dev/loop0 issue.

@remibergsma you are right, we don't need to up the sysvm template version yet. For other version numbers mentioned, @pdion891 can you add thos location in the build_asf.sh and setnextversion.sh scripts?

@remibergsma I think we will need to create new systemvmtemplate for 4.7.0 if we'll get the openswan->strongswan patch merged.

@bhaisaab Sure, that would be a good reason. But it's not ready so let's bump when we merge that PR.

I have updated release scripts as per @DaanHoogland comments but didn't change template version, based on @bhaisaab I would suspect we will upgrade sysvm on 4.7, soon ?

Thanks @DaanHoogland for the location of those scripts, I was wondering how to automate this version changes! :)

@pdion891 @bhaisaab In about two weeks (Dec 7) we freeze for 4.7.0. That would be a nice time to look back and see if the systemvm template needs to be bumped or not. Right now, there is no PR merged yet that requires a new version, so I don't want to bump it now. It's just too damn annoying upgrading all systemvms if there is no reason. Once there is, we will bump it of course.

Let me add it to the release procedure, to check at freeze time whether the systemvm version needs to be bumped. We will most likely have releases coming where we don't need to bump the version.

Also @pdion891 could you please squash the commits. Thanks!

@pdion891 I'm OK with this, but I think you do not need to change the version in tools/docker/systemtpl.sh until there is a 4.7 version. Otherwise it will result in a 4.4

@pdion891 LGTM, but you'll need to fix the version again for master/4.8 and squash the commits

@pdion891 please rebase against latest and squash commits

Thanks for the reminder Rohit. I will update this PR accordingly.

replaced by #1435