New release planning

[bures]

I'm planning the new major release of Mailtrain. I think we had v2 beta sticking around for quite long enough to mitigate the worst bugs.

My plan is the following:

• rename 'master' branch to v1
• rename 'development' branch to 'v2'
• make 'v2' as the default branch
• add notice to 'v1' README that this version is no longer maintained and that a transition to v2 should be done

Please, any comments, objections, etc.? (@andris9 and anyone else?)

[vibhoo]

Sounds good. It would be great if up-gradation procedure is also mentioned.

[iwebpush]

Hi, eagerly waiting for new releases. any idea when this will be implemented.

[joker-x]

I think that is better keep master and development branches:

• master will contain the last stable version, when we publish the new major release will be v2
• development will contain the last changes for developer and bold users
• only we need create the branch v1 and notice in README

So, who install cloning the repository don't need to change anything.

[saschafoerster]

I am looking forward to the new release! :)

[terdinatore]

Even tough there has not been a V1 Docker image so far you could generate an V1 image from the V1 branch and push it to Dockerhub. Also I would suggest to generally create new versions numbers with every few pull requests again as you did in the past. These version numbers could then also be used to tag Docker images on Dockerhub.

It is generally considered bad practice to use the latest tag in Docker for production because unsolicited version upgrades can happen quite easily.

[saschafoerster]

@bures I am using checkout v2 as described in the readme. Right now I wonder, what to do, if I want the newest features. Is v2 like "latest"? And is it sort of stable? Thank you for your really nice work keeping the mailtrain running! 🚂

[bures]

V1 is deprecated. V2 is sufficiently stable. I have been running it in a mid-scale production (approx. 20 users, 20 lists, 20 campaigns a week) for about 2 years without any major problem. Some features are however not well tested since I don't use them - triggered campaigns, grapejs, RSS campaigns.

[saschafoerster]

I found out how to change it: I used this (and the docker-image wasn't updated in a while)

  mailtrain:
    image: mailtrain/mailtrain:latest

I did then clone the repository into the subfolder /src git clone https://github.com/Mailtrain-org/mailtrain.git src and changed the docker-compose.yml:

  mailtrain:
    #image: mailtrain/mailtrain:latest
    build:
      context: ./src

For updates I can now do this:

cd src
git pull 
cd ..
docker-compose stop 
docker-compose build 
docker-compose up -d

Of course: now docker-releases would make it a bit easier. :)

[bures]

Perfect. If you or anyone else would be willing to maintain the docker image, I'd be happy to give you push rights to dockerhub.

[ghost]

V2 is sufficiently stable. I have been running it in a mid-scale production (approx. 20 users, 20 lists, 20 campaigns a week) for about 2 years without any major problem.

For the record, we've been running a V2 instance for 11 months now without much issue as well.

We have ~100 lists, delivering up to 200,000 messages per month across 20-30 campaigns.

[talheim-it]

We are going to start with the development and testing of mailtrain v3 in the next weeks.

You are welcome to help us with the testing as soon as the first release candidate is available.