Incremental Build Releases
by Chris Labombard · in iTorque 2D · 03/24/2011 (7:20 am) · 34 replies
I wanted to bring up the idea of having a faster turn around on releases by allowing for tiny point releases with 1 or 2 very small features or bug fixes, possibly community driven.
What it is:
- Release a new version of iT2D 1.4.1.X weekly or as soon as a stable build is ready with a new feature or fix (even a tiny fix)
- Release it as a zip file instead of an installer (decreases testing time, and I find installers annoying)
- Allows for community fixes, features etc. to be added in by the developers
- Allows for community testing, which you are probably seeing with 1.4.1 release is a huge benefit
What it does for our community:
- Keeps the community excited
- Lets the community actively contribute
- Gives GG employees extra help by default
- gives us faster turn around on new builds
Just wanted to throw this out to the developers. I think it is by far the best way to get the product even more stable, with faster releases, and more features.
For example, Conor is porting in Multi-touch support. I believe it's a small addition but if a dev could take his diff of 1.4.1 and plug it in and release a zip I think it would be a huge boost and immediately effective.
What it is:
- Release a new version of iT2D 1.4.1.X weekly or as soon as a stable build is ready with a new feature or fix (even a tiny fix)
- Release it as a zip file instead of an installer (decreases testing time, and I find installers annoying)
- Allows for community fixes, features etc. to be added in by the developers
- Allows for community testing, which you are probably seeing with 1.4.1 release is a huge benefit
What it does for our community:
- Keeps the community excited
- Lets the community actively contribute
- Gives GG employees extra help by default
- gives us faster turn around on new builds
Just wanted to throw this out to the developers. I think it is by far the best way to get the product even more stable, with faster releases, and more features.
For example, Conor is porting in Multi-touch support. I believe it's a small addition but if a dev could take his diff of 1.4.1 and plug it in and release a zip I think it would be a huge boost and immediately effective.
About the author
I have been a professional game programmer for over 5 years now. I've worked on virtually every platform, dozens of games and released a few of my own games, including 2 iPhone titles and a title waiting release on Big Fish Games.
#2
Some bugs are tiny and immediately fixed (or should be) and it would be nice to get them IMMEDIATELY if we want them.
03/24/2011 (8:28 am)
Zip and upload is not a lot of overhead, I hope.Some bugs are tiny and immediately fixed (or should be) and it would be nice to get them IMMEDIATELY if we want them.
#3
Again I don't know all thats going on behind the scenes, but it would be nice to be able to look at list and say ok official multi touch will be working in Aprils release, shooter tutorial will be in May, Game Center support will be ready in June, etc...
If they want to implement community additions even better as its free work for them :D. Will all of this happen, probably not, but it really would help the community a lot. Especially because when people look to start investing in new engines one of the first things they do is look at the community and how enthusiastic people are on the forums. Its how cocos2D became so popular so fast. Frequent updates with the most active community ever. They still are growing super fast and have a great community. Theres no reason an awesome product like iT2D can't have that same success.
03/24/2011 (8:40 am)
While a 1 week turn around time might be a bit too quick I would like to see a more agile approach taken. It would be nice to see a list of features/bug list that will be implemented hopefully by the end of the year. Then maybe have a monthly release that will knock a feature/bug or 2 off the list. I agree that this will really help the community stay positive rather than the forums turning into a cryfest with a bunch of hating. Again I don't know all thats going on behind the scenes, but it would be nice to be able to look at list and say ok official multi touch will be working in Aprils release, shooter tutorial will be in May, Game Center support will be ready in June, etc...
If they want to implement community additions even better as its free work for them :D. Will all of this happen, probably not, but it really would help the community a lot. Especially because when people look to start investing in new engines one of the first things they do is look at the community and how enthusiastic people are on the forums. Its how cocos2D became so popular so fast. Frequent updates with the most active community ever. They still are growing super fast and have a great community. Theres no reason an awesome product like iT2D can't have that same success.
#4
@Juntoau
Cocos2D had a history as a strong open-source library prior to the iPhone version's release. It was also one of the only free options at the time. It's a great programmer community and it is always exciting to see what the project maintainers push into the releases. I don't think I'd go so far as saying it is the most active community ever, but it is a great community of knowledgeable developers.
03/24/2011 (9:13 am)
I would be remiss if I said that we had not considered ways to get releases to the community in a faster, more impactful way. We have been in the process of adjusting how we work and Mich's documentation pushes have been a good example of some of our initiatives and tests. We are still a ways away from making any decisions on release structures and such, but discussion like this *really* help us figure out how you guys best use our products and how we can get them into your hands in the fastest and most stable way possible.@Juntoau
Cocos2D had a history as a strong open-source library prior to the iPhone version's release. It was also one of the only free options at the time. It's a great programmer community and it is always exciting to see what the project maintainers push into the releases. I don't think I'd go so far as saying it is the most active community ever, but it is a great community of knowledgeable developers.
#5
Conor just ported in multi-touch and posted how-to. (*Note, he hasn't yet)
Employee (read Mich) sees it and puts it in his official build.
Does a quick test.
Zips it.
Uploads it as 1.4.1.1.
Done.
We all now have it and it WILL get tested because we will use it in our projects.
03/24/2011 (9:19 am)
It's not even that I want to see a structured weekly build (though obviously a build schedule is necessary)... What I want to see is for example:Conor just ported in multi-touch and posted how-to. (*Note, he hasn't yet)
Employee (read Mich) sees it and puts it in his official build.
Does a quick test.
Zips it.
Uploads it as 1.4.1.1.
Done.
We all now have it and it WILL get tested because we will use it in our projects.
#6
03/24/2011 (9:23 am)
We used to do something similar with patch files, but training people to use patch files ended up being more difficult than creating an installer and jumping through all the hoops that that entails. Somewhat like teaching people to use CVS back in the day.
#7
WinMerge (or Mac equivalent) is all you need to go from whatever you're using to the newest point release.
03/24/2011 (9:27 am)
I prefer the complete version instead of a patch. Then I can download and go from any mini-point release download.WinMerge (or Mac equivalent) is all you need to go from whatever you're using to the newest point release.
#8
IMO
Frequent Updates -> Happy Users
Well Known Roadmap -> Excited Users
Happy + Excited Users -> Enthusiastic Community
Enthusiastic Community -> Community Growth(more cash money for you! :D)
Thats all I was trying to get at. :D
PS Also I would say I would prefer the installer, however wouldn't be against other patching methods.
03/24/2011 (9:41 am)
@David It's true they had a strong following before hand with Cocos2D or at least I was told that by others as well.(And saying THE most active community I'm sure isn't accurate) But I jumped in early into the fray early in Cocos2D-iPhone's life, and they exploded with new users very quickly.(Again I understand that it being free and already having a large Cocos community helped a lot with that.) I just think a large part of that growth was due to the excitement and activity of the community.(Again part of that enthusiasm came from it being free, however iT2D is now very inexpensive for such a good engine)IMO
Frequent Updates -> Happy Users
Well Known Roadmap -> Excited Users
Happy + Excited Users -> Enthusiastic Community
Enthusiastic Community -> Community Growth(more cash money for you! :D)
Thats all I was trying to get at. :D
PS Also I would say I would prefer the installer, however wouldn't be against other patching methods.
#9
03/24/2011 (9:48 am)
All the installer really does is unzip the folder into a directory. 
#11
First incremental release solid -> Happy users
Second incremental release solid -> Happy and more trusting users
Third incremental release bugged -> Pissed off users who forget the happy past
Do we want to take a more agile approach to development? Yes. We are already heading down that path. However, one week turn around is not possible. At a minimum, two weeks would be needed. One week of development and one week of QA.
Also, we need to get some more people on staff to handle this. Scott and I are the only two right now who can handle iTorque 2D releases, but that is not our only responsibility. When we get another iOS developer and more QA in here, the idea of incremental releases becomes more feasible.
Good thread, though. I like the enthusiasm and I'm very happy to hear our plans would make others excited and grow the community.
03/24/2011 (10:09 am)
@Juntao - You left something out:Quote:Frequent Updates -> Happy Users
Well Known Roadmap -> Excited Users
Happy + Excited Users -> Enthusiastic Community
Enthusiastic Community -> Community Growth(more cash money for you! :D)
First incremental release solid -> Happy users
Second incremental release solid -> Happy and more trusting users
Third incremental release bugged -> Pissed off users who forget the happy past
Do we want to take a more agile approach to development? Yes. We are already heading down that path. However, one week turn around is not possible. At a minimum, two weeks would be needed. One week of development and one week of QA.
Also, we need to get some more people on staff to handle this. Scott and I are the only two right now who can handle iTorque 2D releases, but that is not our only responsibility. When we get another iOS developer and more QA in here, the idea of incremental releases becomes more feasible.
Good thread, though. I like the enthusiasm and I'm very happy to hear our plans would make others excited and grow the community.
#12
03/24/2011 (10:15 am)
@Michael 100% agree with you that 1 week was way too fast, that's why I threw out the month mark which seems much more realistic. :D
#13
What about the little things floating around the forums? The tiny little fixes? The tiny little features? The little bugs Alistair has reported?
We have to wait weeks or possibly months to get them. Why can't we just get a quick code dump, when the dev's have it fixed in their build, as a mini point release? Let us test your code. If one is buggy, it doesn't matter. Just fix it and resubmit it as the next mini-point release.
Am I off track here? Am I making sense?
03/24/2011 (10:20 am)
When you're talking about adding a new feature into the engine or a major fix then I agree, you need at least a 2 - 4 week release schedule. I didn't mean to apply differently. What about the little things floating around the forums? The tiny little fixes? The tiny little features? The little bugs Alistair has reported?
We have to wait weeks or possibly months to get them. Why can't we just get a quick code dump, when the dev's have it fixed in their build, as a mini point release? Let us test your code. If one is buggy, it doesn't matter. Just fix it and resubmit it as the next mini-point release.
Am I off track here? Am I making sense?
#14
I probably would not need a week to fix just one bug...maybe even two. For anything over two bugs or a new feature, I would want a full week to fix and test on my own. That's assuming the bug fix isn't something really big and requires an estimate over a few days.
An official build WILL NOT go out to the public unless it passes my smoke test and it goes through a QA cycle (typically 5 working days). If we want to put out an "unstable" release, it still has to go through my smoke test and QA's smoke test. This process has not been finalized, though, so do not hold me to any of this.
03/24/2011 (10:36 am)
Quote:We have to wait weeks or possibly months to get them. Why can't we just get a quick code dump, when the dev's have it fixed in their build, as a mini point release? Let us test your code. If one is buggy, it doesn't matter. Just fix it and resubmit it as the next mini-point release.
I probably would not need a week to fix just one bug...maybe even two. For anything over two bugs or a new feature, I would want a full week to fix and test on my own. That's assuming the bug fix isn't something really big and requires an estimate over a few days.
An official build WILL NOT go out to the public unless it passes my smoke test and it goes through a QA cycle (typically 5 working days). If we want to put out an "unstable" release, it still has to go through my smoke test and QA's smoke test. This process has not been finalized, though, so do not hold me to any of this.
#15
Sure, that works for you. You are someone who has used it and knows what the release would entail. If I introduce another bug or two that doesn't really affect you, then things are gravy. However, what if we have someone buy the engine the day I release something unstable and it breaks their user experience? We have to consider every user, which is why we finalized a rock solid QA process that is non-negotiable.
03/24/2011 (10:38 am)
Quote:If one is buggy, it doesn't matter. Just fix it and resubmit it as the next mini-point release.
Sure, that works for you. You are someone who has used it and knows what the release would entail. If I introduce another bug or two that doesn't really affect you, then things are gravy. However, what if we have someone buy the engine the day I release something unstable and it breaks their user experience? We have to consider every user, which is why we finalized a rock solid QA process that is non-negotiable.
#16
EDIT: In response to your last post... That is why it is not an actual release. Just an unstable, unverified mini point release. The last major release would still be the prominent, recommended release.
03/24/2011 (10:39 am)
Mich - What you describe is precisely what I had in my mind.EDIT: In response to your last post... That is why it is not an actual release. Just an unstable, unverified mini point release. The last major release would still be the prominent, recommended release.
#17
03/24/2011 (12:06 pm)
@michael - Just make it clear that it's a WiP/dev build. By default provide only fully tested releases to new customers and perhaps have an opt-in profile option for beta releases.
#18
03/24/2011 (12:10 pm)
Mmm, confusing logistics....or we err on the side of caution, keep it simple and treat all equally. Also, keep in mind Associates will get access to what's directly in the repository. I think that's what you all really want =)
#19
03/24/2011 (12:14 pm)
Yes, that is what I want.... Unfortunately, I'm not an Associate. :(
#20
03/24/2011 (12:19 pm)
@Chris - Fret not, for we are rebuilding the Associate program and will be opening that path up again...if you are the kind of person interested in being an Associate. 
Torque 3D Owner Alistair Lowe3
Perhaps not every week to not create large overheads for GG but fairly frequently?
This would definitely be helpful, take TGB 1.7.5 for example, Torsion debugging support is 100% broken and requires a patch to be applied manually and a recompile, not great for attracting new users. Likewise applying this patch then breaks the Platformer kit and so having a dev/beta build of this to match would be a great help.