Cockatrice: Release Management Improvements

[poixen]

The current release cycle feels like it could be improved. Here are some thoughts:

1. Establish a regular release cycle
   
   
   
   • Users know when a new build will be delivered
   
   
   • Developers can align tasks to release date
   
   
   • Testing period can be planned in advance
   
   
   • Organisational consistency
   
   
2. Consistent versioning
   
   
   
   • Current versioning system is split between 2 naming conventions:
     
     
     
     
     
     • Client hash (not human readable)
     
     
     
     • Arbitrary named releases (hard to keep track of)
     
     
     
   
   
   • Confusing for users / developers / management
   
   
   • Hard to distinguish between major and minor changes and releases
   
   
   • We should standardise the version naming convention
   
   

Would be good to discuss with the rest of the team, so add feedback in the comments.

[woogerboy21]

My $0.02...

Establish a regular release cycle

Sounds great, though since we dont have consistent developers or really any type of development focus not sure you would end up with situations were the release cycle would come to date and nothing has really changed.

Consistent versioning

Drop names, stick with numbers generated by git or whatever product is used for code base management.

[tooomm]

Establish a regular release cycle

Sounds great, though since we dont have consistent developers or really any type of development focus not sure you would end up with situations were the release cycle would come to date and nothing has really changed.

This doesn't sound too bad to me. If there is a new release with just a few fixes... it's ok. Otherwise the users would wait even longer for fixes!
And if there is no development at all for one year for example there is nobody releasing either. :P

It could be like with Ubuntu, twice a year, with the year and month as numbers in the name. 15.10,16.04,16.10, ...

I highly like some kind of cycle!

[woogerboy21]

And if there is no development at all for one year for example there is nobody releasing either.

Your trying to set a precedence on when users should expect improvements and all I'm saying is we aren't a business and thus there might never be. Personally I'm really ok with trying anything.

One of the larger issue's I see is the fact that we just don't have enough developers/testers/etc to really implement any code work / testing concept (if you ask me). Take for example the report of replay watching being broken. That seems like a pretty big deal to me, one could argue if we had proper testing before deployment it should have never happened, but we have no testing scripts or steps. And if you ignore that fact there has been no real involvement with the fix. I jumped on it but haven't seen or heard from anyone about the PR fix I put in place. No idea if the user has done testing, no idea if anyone reviewed any of the code... nada. And we are going on how long?

Any idea's on how time frames would be handled / defined?

[tooomm]

We release somehow not-perfect software all the time. I agree with you that we'll never be a serious business and that we'll never have adequate testing. But we all now that, that's not the point. We most likely can't change that completely either.

At least for me, this is mainly about having more fixed dates for releases and a proper/new naming/versioning scheme.
Right now we have basically just releases when somebody calls for it, could be 2 month or 10 month.

About the time frames:
We could agree to not do major features/changes in, let's say, the last month upfront the release for example. "Test" for ourselves (and some early adopters who happen to download it) while using the application during that time... apply some fixes, cleanup the biggest mistakes and crashes - and that's it. It's even more "testing" than we do currently before releases. ;)
Once we get channels working (#2321), this last 30 days (=feature freeze), could be beta channel, so we even get some more testers.

If most people don't like more fixed dates, ok... then let's think about his 2nd point.

@Daenyth what's your thought on this topic?

[Daenyth]

I definitely agree that we would be helped by:

• Consistent versioning info. Let's add a basic semver version in addition to what we're doing. Commit is still useful for us to track down issues. Build date is useful for support tickets. Codenames I don't care about either way, but some people find them fun.
• Testing period planned before release (real RC process)

I don't think releasing on a schedule would help us. What would be good, I think, is setting a fixed testing window and heavily promoting RC builds, maybe tying into release channels so people can opt into auto updating to RCs with an easy way to downgrade - #2321

So let's say:

When we think we're ready to release

• Announce the intent
• Immediately make an RC build
• Promote the RC build
• During RC period, freeze on adding new features or strings. Add only bugfixes, change strings only for outright errors
• When RC period is done, grab latest translations, release the build.
• Release, update the site to remove RC link,

One key point is that the RC period would last for a fixed length of time + time to fix any blocking issues. Say 1 month.

To be roughly in line with semver, our x.y.z could be
x - Major protocol version. Limited-to-no cross compat between versions. Version 1 would be the ancient XML format. If we ever totally rewrite the protocol that would be 3. I'll call the current version 2
y - Feature changes
z - Bugfixes, string tweaks, minor ui polish; roughly our old -rev versions

So let's call the current version 2.10.1

[Daenyth]

Bintray artifacts can be named like
Cockatrice_platform_date_version_type.ext
for example
Cockatrice_win32_2017-01-01_2.10.1_release.exe
Cockatrice_osx_2017-01-01_2.10.1_release.dmg
Cockatrice_ubuntu16.06_2017-01-01_2.10.2_rc.deb
Cockatrice_..._2.10.1_abcd123_snapshot.ext - for a git snapshot build

[tooomm]

Bintray artifacts can be named like
Cockatrice_platform_date_version_type.ext
for example
Cockatrice_win32_2017-01-01_2.10.1_release.exe
Cockatrice_osx_2017-01-01_2.10.1_release.dmg

Did you pick that order for a particular reason?
It would look smoother and would be easier to read if the only different part is more at the end (platform) and both number sequences (date and version) are not following each other:

So I would suggest date_Cockatrice_version_platform_type.ext:
2017-01-01_Cockatrice_2.10.1_osx_rc.dmg
2017-01-01_Cockatrice_2.10.1_ubuntu16.06_rc.deb
With that it would also be possible to easily sort for the most recent version by date if there are plenty in one folder for example.
Though it might not be ideal if the filename doesn't start with the app name...

[Daenyth]

I don't have strong feelings on it. Version and type should go together though

[tooomm]

Having "version" and "type" together really makes sense:
(Maybe even prefer the later, it would also sort properly due to incrementing version numbers)

2017-01-01_Cockatrice_2.10.1_rc_osx.dmg
2017-01-01_Cockatrice_2.10.1_rc_ubuntu16.06.deb

Cockatrice_2.10.1_rc_2017-01-01_osx.dmg
Cockatrice_2.10.1_rc_2017-01-01_ubuntu16.06.deb

[Nightfirecat]

@tooomm :+1: for the latter example, looks clean.

[Daenyth]

Agreed, Cockatrice should be first.

[skwerlman]

Would date be when the change was committed or when the binary was built?

[Daenyth]

Build date typically, but in practice it won't differ for automatic builds

On Fri, Jan 6, 2017 at 2:01 PM skwerlman [e-mail] wrote:

Would date be when the change was committed or when the binary was built?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/2341#issuecomment-270978062,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5NPkJwkn7djkASoduzs1UC6Yrh8MIks5rPo-bgaJpZM4LaoGU
.

[tooomm]

When do we start utilizing this by the way?
The names would be manually incremented anyway, correct? Considering:

To be roughly in line with semver, our x.y.z could be

x - Major protocol version. Limited-to-no cross compat between versions. Version 1 would be the ancient XML format. If we ever totally rewrite the protocol that would be 3. I'll call the current version 2
y - Feature changes
z - Bugfixes, string tweaks, minor ui polish; roughly our old -rev versions

I think the release names we use right now are still fun and maybe even a trademark of cockatrice.
We could think about using them in the About window, advertisement and announcements for main releases only.
It needs a little back-and-forth though, since I guess we would need to pr the name to the About window, release and immediately pr the name out again to not have it in continuous developing builds.
But we have to push the new version number to About manually anyway if I understood thinks correctly... so.

[Daenyth]

We can still use release codenames, they just won't be used for version info.

I think since we're planning to release tomorrow it's a little too soon. But let's target this for next release after that, since it requires updater changes (again)

[ZeldaZach]

The release occurred earlier today, but yes we can push for it happening at the next release!

[tooomm]

@Daenyth: it requires updater changes (again)

Which changes do you think are needed in the updater @ctrlaltca ?

Linking: https://github.com/Cockatrice/Cockatrice/issues/1036 and https://github.com/Cockatrice/Cockatrice/issues/1751

Also consider this comment for a different wording on 32/64bit versions for win...

[ZeldaZach]

Looking at the specs of this, we have just implemented semvars with both the git tag and in client, so I feel that's complete. I do not feel we should hold ourselves to regular update cycles (like Ubuntu) as that puts too much pressure on the team. I feel this ticket is complete.

[Daenyth]

Having auto updater release channels relieves a good chunk of the want for a release cycle imo