Present: abma, hoijui, jK, Tobi, zerver
- release 83.0 as is?
- version scheme
- release 84.0
- stay at <synced>.<unsynced> scheme and see if its works
>> Tobi joined!
>> jK joined!
>> abma joined!
>> zerver joined!
abma: [RoX]Tobi: i can't take part this meeting again :-/
abma: i'll be around here at midnight
<< zerver left!
>> zerver joined!
zerver: mantis does not work o_O
jK: Licho moves mysql to new server
>> hoijui joined!
abma: [RoX]Tobi: i can't take part this meeting again :-/
abma: i'll be around here at midnight
hoijui: just kloot missing then
hoijui: he committed not long ago
hoijui: so.. question is qhether to set release live, or make a 84.0 and set that live
hoijui: jk wants to set 83.0 live, to get more reports first
hoijui: Licho offered to use 83.0 for ZKL users only, which is less troublesome, as they have effective multi-version support already
zerver: I'm pretty sure there will be more bugs found so it does not matter really, only making a 84 is more work
jK: only bomber & cmd queue bugs are bit annoying
jK: still not game breaking imo
zerver: what games have the command queue issue? BA seems unaffected
zerver: but ZK has multi version support :)
jK: ZKL has
jK: duno how many ZK players use SL
hoijui: mm ok
hoijui: yeah sounds like a release would be ok
* zerver Slaps [RoX]Tobi around with a large PeeWee!
hoijui: i guess we should wait till the server is up and runnign again, right?
hoijui: so people can ask for help and post bugs on mantis nad forum and such
hoijui: would be bad if new spring is fial for them, and the site is down too :D
jK: server must be up, else we can't access wiki
Tobi: best wait at least until licho is done messing with the server
Tobi: then use zkl to test some new version
Tobi: doesn't hurt if 83 is never deployed for all IMO
hoijui: yeah that is true
hoijui: the only reason to deploy it is, to get more feedback
jK: k we have to wait till tomorrow no matter what
hoijui: thats jks argument
jK: if bomber bug & framenums in chat console, get fixed it might be worth a new release
jK: btw we still need vote how the next bugfix release gets named
jK: hoij wants 84.0 (he wants 2nd number after dot for unsynced releases)
jK: I don't want to drop the ability to differ between major & bugfix releases
jK: so I prefer 83.1 for synced bugfix release
hoijui: that was already decided
>> abma joined!
jK: show me where it was decided
jK: it was only decided that it will be 83.x and not 0.83.x or 1.x
hoijui: it was decided to use this branching model RC, and that clearly state show the version is done
hoijui: one dot for releases, two on develop
hoijui: and the second number is non sync relevant
jK: no one understood your images, neither did we voted on them, neither did you had all possibilities in those (e.g. <major>.<synced>.<unsynced> was missing)
hoijui: jk... you shoudl have come earlier with that
hoijui: also this was clear
hoijui: you did not like it, cuase it did not contian minor version anymore
jK: it wasn't and it is hard to talk with you about it
hoijui: now you say it was unclear, and nobody understood it
hoijui: thats 180
hoijui: reading the minutes again: http://springrts.com/phpbb/viewtopic.php?f=73&t=26899
hoijui: Tobi, zerver and me agreed on it
hoijui: you did not
hoijui: kloot and abma were not around
jK: no, the meeting was like this: you: why not 1.x? me: dislike it ... you: why not 2011.1? me: I want to be able to differ between major & bugfix ... much flame & anger ... tobi: prefer 83.x ... ... we/you agree on 83.x
jK: it was never the topic to drop minor after tobi said he prefers 83.x
hoijui: tobi said that no minor version is requried
hoijui: cause we cna just upp the major by more then 1
hoijui: if it is a bigger release
hoijui: we decided not to do that wiht 83 (eg 85 or 90), cause we alreayd told everyone that there will be an 83
hoijui: ... i would have been fine with 85 or 90 too
jK: k, he said to drop minor
jK: but it still wasn't clear/decided if hotfix should be increased or major
hoijui: not sure what you mean
hoijui: increased . when?
Tobi: hotfix = doesn't break sync
Tobi: anything that breaks sync must bump some version number that indicates sync is broken
Tobi: regardless of how small the actual fix is and how 'hot' it is
Tobi: IMHO the idea is that hotfix is for minor fuckups in the installer or so mostly
jK: jumping from 83 to 84 for a bugfix release is crap imo
hoijui: SL also uses tha scheme btw
jK: SL has no syncs, nor major releases
hoijui: it does not matter so much.. we are not creating art
hoijui: and this simple scheme is easier to get right for users
Tobi: hence, later on we can do things like go from 83 to 90 if we have another 3k commits
abma: hmm... imo we have two possibilities... next version is 83.2 (as develop already is 83.1?) or next version is 84 ?
Tobi: so we can do 91 for bugfixes or so
hoijui: abma. develop is 83.0.1
hoijui: yeah that sounds perfect to me, what tobi said
Tobi: afaics there is no technical reason to have major.minor that both indicate sync is broken
jK: there is no technical reason to have a version at all
jK: the version is needed that users have the ability to differ 2 numbers
jK: e.g. 82.x has a totally different feature list than 83.x
jK: with a bugfix release the feature list normally doesn't get increased
hoijui: we can also (in addition to the igger jumps) add some codename ot the release. like unbuntu, if you liek that
hoijui: this one coudl ebe the assimp release
Tobi: in practice ppl even sneaked features in bugfix releases
hoijui: yeah jk, we already said it should have been 85 or 90 or so
hoijui: yeah als otrue
hoijui: we could make the bugfix release 90, instead of 84.. if you preffer that (in case we dont go live with 83 at all, that would even kind of make sense, to users, still)
jK: so you want just too reach higher numbers faster ...
Tobi: IMHO ideally we get our development at a decent level where we don't even need bugfix releases, and can just make a release every 1-2 months
jK: release 304.1 \o/
Tobi: I don't mind how fast we reach higher numbers, as long as version numbers are strictly increasing
jK: too high numbers are `unnatural`
hoijui: yeah, if we have global multi-version support, this stuff should get muhc better
jK: except they indicate the year
jK: <[ARP]hoijui_g2> yeah jk, we already said it should have been 85 or 90 or so > or so?
jK: you just make it vague
jK: so there won't be strict rules how a release get named
jK: making thinks even worse
jK: e.g. so next bugfix release might be 84.0, what is ROAM release then? 85.0? 90.0? 91.0?
hoijui: yeah exactly, no strict rules
hoijui: what is bad with this?
hoijui: as tobi said, it just has to increase
hoijui: if we say, major releases are %10=0
hoijui: then we have no more lax rules then we had in hte old system
hoijui: you also had to decide what is major and what not
hoijui: that is no way different, depending on the shceme
hoijui: -? you are starting to drama, kind of
Tobi: in my experience with spring there have never been true bugfix releases, we tried it sometime, but in practice they were always conceptually equivalent to a normal release, except with a lot less changes, and a higher percentage of fixes
abma: so just do a +1?
Tobi: that is what I'd go for yeah
abma: if someone wants to know changes, he always have to read changelog...
Tobi: and then try to not need to do quick extra releases
jK: not true we had multiple bugfixes release that weren't branches of develop
Tobi: what is not true?
jK: <[RoX]Tobi> in my experience with spring there have never been true bugfix releases, we tried it sometime, but in practice they were always conceptually equivalent to a normal release, except with a lot less changes, and a higher percentage of fixes
hoijui: they never were branches of develop
hoijui: but that is not what tobi talks about
hoijui: not git branching conceptually
jK: so we had releases that differed from the develop/master branch to that time
abma: we often break sync, so there are few possible bugfix releases
jK: and with the current version scheme those situations would collapse
jK: e.g. develop is tag 85 and we want a bugfix release of tag 84
hoijui: that does not fit into the branching model
jK: how is this bugfix named 86? (it doesn't contain the 85 commits)
hoijui: jk.. dont start it all over again
hoijui: we want the new brancign model cause hte old one was fail
hoijui: it was hell for the release manager, unclean
hoijui: that was all decided already
jK: how was it the hell for release managers & unclean?
jK: the new branch model doesn't symplify cherry-picking & merging
hoijui: it eliminates cherry picking
jK: the develop branch contains exprimental commits that shouldn't be in a bugfix release
jK: so you still need to cherry pick bugfix commits from develop branch
Tobi: in the model a release branch should have been made containing all fixes, iirc
Tobi: dunno if that has been done
Tobi: although I might be confused with a different version of the model
hoijui: no, that is true
Tobi: but that is how one typically eliminates cherry picking
jK: if so we have to do commits twice (once for develop & once for release branch)
hoijui: well.. kind of
Tobi: the assumption is that those fixes aren't so breaking that you can't even develop without them
jK: just increasing the work even more and causing even more merge problems
hoijui: if htere is no release branch, then all commits on develop will be in next major release
hoijui: (major as in, the major version number)
Tobi: you can merge release branch into develop at any time
hoijui: jk has a problem wiht that:
hoijui: if we would merge ROAM into develop right after 83 release
hoijui: and then want to make a major release 84 shortly after 83
hoijui: then it woudl laready contian ROAM
hoijui: that is true
Tobi: so if release is so utterly broken that it isn't even possible to develop on develop before having the fixes in the release branch, you can merge the release branch into develop after doing this fix in the release branch
hoijui: but that is not a problem, agian, if we have propper multi version support
hoijui: yeah.. that is not jks issue
hoijui: (i think)
hoijui: it would just be utterly stupid also, to merge ROAM right afte a release form which we all know that it is gona fail big time
hoijui: so of course it wont happen
jK: you want the develop branch always in a releasable state
jK: I don't see it like that
jK: it wasn't like that it won't be
jK: e.g. 0.82.7.1 was released >half year after 0.82
Tobi: correct, it won't be (cause we fail too much), but the ideal should always be that develop is in releasable state
hoijui: no, that is not what we want
jK: so the 0.82.7.1 branch _totally_ differed from the master/dev branch when it got released
Tobi: use topic branches
hoijui: should we make a release branch now, btw?
hoijui: i guess we could
hoijui: would just have to make sure that also kloots starts committing there
jK: <[ARP]hoijui_g2> it would just be utterly stupid also, to merge ROAM right afte a release form which we all know that it is gona fail big time > and there it freeze development, before a release no one can commit smaller changes & after it neither
Tobi: ROAM is a small change?
jK: feature branches become harder to merge ...
jK: so how long should this freeze time be then 3weeks? (very hard to reach a 2month release cycle then)
hoijui: <[ARP]hoijui_g2> but that is not a problem, agian, if we have propper multi version support
jK: neither very good for the devs themselves (can't commit stuff they did and later just drop it etc.)
hoijui: also not if you have a release branch
Tobi: the point hoi made was just to be a bit pragmatic with merging huge branches
jK: with a release branch you need to cherry-pick again
Tobi: features go in develop
Tobi: fixes go in release branch
Tobi: at the end of release branch, you release, and you merge release branch into develop
jK: so the bugs are unfixed in develop ...
Tobi: the merge of release branch into develop can optionally be done earlier (and multiple times) if they are so bad they block development
hoijui: no, yo ucan merge release branch into develop at any time
hoijui: maan jk
hoijui: you never got the model at all ti seems, and start thinking about it now
jK: that's the same as cherry-picking
hoijui: no it is not
jK: merging single commit ~= cherry-picking
jK: with the same merge conflicts
Tobi: but you won't merge after every single fix
hoijui: yeah ok.. wiht same ancestry
hoijui: and with certain config settings
Tobi: yeah true, it's actually pretty different
Tobi: the idea is, that most of the fixes are not so severe that they *need* to be merged into develop immediately
Tobi: (err, the bugs were not so severe that the fixes *need* to be merged ...)
<< abma left!
>> abma joined!
hoijui: are we now done wiht this, it is getting ridicuous (so sure that is right
Tobi: so if done right, this will mean that for a release branch of, say, 50 commits, only 1, 2, maybe 3 actions (merges) are needed
Tobi: while with cherry picking 50 actions would be needed
Tobi: for a similar result
jK: then any bugfixing needs to be done in release branch
hoijui: as long as ther is one
jK: so ppl need 2 repo or switching between them
jK: <[ARP]hoijui_g2> as long as ther is one > there must be one
jK: else it freeze dev branch
Tobi: it can be created in retrospect from the tag, but I think that is a bad idea
Tobi: as it increases the threshold for ppl to put fixes in the not yet existing branch
abma: maybe examples help to explain?
Tobi: btw, locally you can do cherrypicking however much you want
Tobi: so you don't really need 2 repo or switch between branches continuously
abma: where to commit bugfixes for the current release?
abma: and what happens on release?
Tobi: bugfixes are committed to the release branch
abma: where to merge ROAM to?
Tobi: on release the release branch is merged into develop
Tobi: ROAM is merged into develop
abma: and from time to time release is merged into the develop branch?
Tobi: if that is necessary, yes
Tobi: for spring the release branch is supposed to contain only non-sync breaking fixes though (right hoijui?)
jK: e.g. if I would want now to work on weapon code, and possibly will break it for 1week, I need that ppl added their bugfixes to the release branch
hoijui: in theory, we could open a new release branch rihgt after release, always
Tobi: [LCC]jK: if you break it, work in topic branch or locally
jK: cause the dev branch is not releasable for that 1 week
hoijui: we can still merge it into develop and not do a release from it
Tobi: otherwise you block other dev from doing stuff for which they need working weapon code
hoijui: the only downside of that is, that devs have to alwyas commit fixes to that branch then
hoijui: hmm.. well.. over time it would cause more merge conflicts
jK: sometimes even minor changes affect huge amount of files, and so making merging very complicates, so you want to commit it as early as possible so others work with your codebase
hoijui: no good idea
Tobi: of course you can break stuff accidentally, that is why its develop, but goal should be to have it always at releasable quality
hoijui: tobi, release brnach cna contina sync breaking fixes too
hoijui: other hting is hotfix branch
hoijui: this its is really stupid now
hoijui: Tobi nad me nboth have more git XP, and both have been release managers
hoijui: als othe guys that made the basics for our current model have lots of git and releae XP
hoijui: we decided all this already
hoijui: we will use this form now on
Tobi: [LCC]jK: yes, so you try to make those changes not break everything for a while, so that you can commit them into develop
hoijui: if it is as fail as you think jk
hoijui: we can still change in a year or two
hoijui: the model is not perfect, but pretty optimal (as in, les fail then "all" other stuff)
jK: I just see ending as this: 1. ppl will stop experimental work for >1month cause a release is near or was made 2. ppl will just commit to dev branch and so doesn't reduce cherry-picks
Tobi: why 1?
Tobi: it's git
Tobi: there are branches
jK: cause dev branch must be releasable
Tobi: that applies *always*
Tobi: if it isn't releasable, other developers can't use it
jK: you don't create branches for minors changes
Tobi: so you effectively take a lock on the whole repo
hoijui: if yo ufail and put your fix on develop instead of release
hoijui: it will not be in hte next release
hoijui: finally someting that forces people to use git correctly
jK: lol ppl don;t even know how to use rebase correctly
Tobi: rebase is a lot more advanced than branching and merging
jK: rebase is much easier
hoijui: i like this feature, cuase as asiad.. it forces people to do it correctly
hoijui: if they fail, they fail
Tobi: hmm I doubt so, in particular for ppl coming from centralized vcs
Tobi: which doesn't have rebase at all, just branch/merge
hoijui: well.. this is about us engine devs mainly
jK: rebase example: you got unpushed commits and want to git fetch/git pull? -> git stash && git fetch && git rebase && git stash pop (&& git push)
jK: don't see it complicated at all
hoijui: .. hello?
hoijui: can we please end this here?
hoijui: or well..ok go on if you like
hoijui: i ma done for today
hoijui: or for yesterday
<< hoijui left!
Tobi: that's a trivial rebase, the only one that is easy to understand IMHO
Tobi: once you get into rebasing branch on top of other commits/branches or interactive rebase it gets complicated I think (if you don't see conceptually what it is doing)
Tobi: at least that is my impression from when I have to explain git stuff to ppl
jK: `git rebase -i` interface is quite simple imo
Tobi: IMHO whole git is simple
jK: not whole
jK: the `git stash`es every where can be annoying
jK: and lineending conflicts can be the hell
Tobi: yes, last one is true
Tobi: anyway it doesn't matter for this discussion
jK: depends the system becomes very complicated with all the branches, unstrict version naming, ...
jK: and complicated system seem to fail more than simple ones
jK: or better the humans working with them fail more
Tobi: the goal ofc is to take advantage of the features of git while adapting some structure
Tobi: instead of doing everything ad-hoc
Tobi: this should make it simpler in the long run, and at least reduce work / spread work more evenly
jK: for the release manager it might reduce work when ppl commit to release branch
jK: but for other devs it becomes more complicated and so I see ppl commiting to dev branch instead
jK: esp. when there is no release branch
Tobi: no one wants to do release when it includes wading through bunches of badly separated commits and cherry picking all that look like fixes into a release branch
Tobi: so the other option then is to do a feature freeze and just always release develop as is
jK: the problem is that it doesn't only freeze before a release, it would also freeze after it
Tobi: that's just because after = before next release
jK: and so stretching releases even more
Tobi: dev who are incapable of learning to branch should just fix bugs only, and others can use topic branches
jK: e.g. linux kernel has like 4week freeze before a release, but directly starting a new branch for dev work
jK: you can't and don't want to move everything into branches
jK: that way each dev would need his own branch for minor experimental changes
Tobi: I never said that
Tobi: you have to be pragmatic
Tobi: for a large multi commit experimental thing you make a branch
Tobi: for something small that most probably doesn't break things you can just commit to develop
Tobi: the point is that you should not hinder other developers with your experimental changes
Tobi: hmm dunno if that is a word... let's say hinder= block
jK: experimental changes don't have to block others
Tobi: again, I never said they have to
jK: many just fail w/o crashing etc.
Tobi: hence you have to be pragmatic
Tobi: if your change is so experimental there is chance some other dev can't work cause of your stuff, you use a topic branch
Tobi: if there isn't, then no one minds if you commit to develop
Tobi: (btw, fail w/o crashing might still block others)
jK: you don't know if there is a chance that it breaks, experimental means it isn't fully tested yet
jK: still it's in development so you don't want to test it fully yet until everything is finished
Tobi: of course you can do a rough estimation of that
jK: tell that zerver who broke build queue after his `fix`
jK: you think you fix something and break something other
Tobi: yes that can happen
Tobi: one example doesn't prove that one can never roughtly estimate the quality of a change
jK: much work in spring is to refactor old code to make it more readable, but cause the old code was such complicated/incomprehensible it can always happen that you forgot a hidden special case etc.
Tobi: still you have some clue of the impact of the changes you make
jK: and your goal was a 1:1 functionality, and so you don't see it a `feature`, and don't see it worth to make a special feature branch for it (else you have to make 10 of them for each code you refactor)
Tobi: the point is, to minimize the amount of time other devs are blocked on you
jK: so if at all you end up with a devname branch where you collect all those refactors
Tobi: the rest is just tools
Tobi: that could be perfectly fine
jK: we had rarelly such situations where devs blocked others, I just see a release blocking devs in the new system
Tobi: topic branch is a better name, it doesn't need to be about a feature
Tobi: could also be a large multi-commit refactoring
jK: means devs don't commit anymore to develop, instead to their own branches (SL system)
jK: and then cherry-pick/merge their branches to develop from time to time, adding a lot merge conflicts
jK: also complicated when another dev made changes you want to merge in your branch
jK: and you have to follow the commit history of 7 branches instead of like atm 1-3
Tobi: that is in your hypothetical situation
jK: I know I am a pessimist ^^
Tobi: I'm off too, I think we should just try and adapt as it works/doesn't work
<< Tobi left!
<< abma left!
<< zerver left!
For those who didn't understand the positions of each person here they are:
Tobi: Wants to release early and often, so he just wants an increasing number. develop branch should always be in a releasable state. Bugfix releases & branches shouldn't be needed in that case -> if something is broken in a release, just make a new one with all changes made to develop.
hoijui: Wants to get rid of dots and release branches, they cause much work for the release manager to cherry-pick commits (hoijui made like all 0.82 releases and esp. at the end it was just the hell to solve merge conflicts).
jK: Wants natural/nice version names & fears develop won't be always in a releasable state or if so devs fear to make commits cause they may break it.