errr... Maybe I'm missing something, but isn't the 3.3.2 release of openfire close to 6 weeks old?
Mike -- we use SVN and branch at the end of every three weeks. We then do QA on the branch and release out of the branch while trunk continually moves forward. The great thing is that trunk never needs to be locked down -- it's always a safe place to check in new work.
Ryan -- yep, you're correct. Openfire is not actually on the train yet. That's the case because so much work has been going into clustering. That will change in the near future.
You guys really should think of a way to automatically upgrade your software w/o reinstalling it.
So far I'm not liking the Train so much. How about spending more time on
regression testing at the "QA station"?
gsmd -- we'd love to implement that in the future. I think it would make upgrades much easier.
ben -- sorry to hear that. Are there some particular issues you've run into? We focused on quality a lot in Clearspace 1.4, so I'd be curious to get your feedback on that release.
Here a couple that I know of off the top of my head:
XMPP Presence stopped working when I upgraded from 1.2 to 1.3.
LDAP authentication broke when I upgraded from 1.3 to 1.4. Can't log in. A new install of 1.4 works but the upgrade is a problem. Presence still not working.
What worries me the most right now is migrating data from Knowledge Base. The all-or-nothing import tool you now have may work well for Jive Software but our users here cannot handle such abrupt change gracefully. It didn't work well for me when I tried it with 1.4 anyway.
I imagine that new customers are most important right now but please don't forget about us KB customers. Thanks.
Ben -- from your description of the presence and LDAP issues, I'm not sure if we're aware of them. We did create a new AuthProvider structure that possibly could have impacted the upgrade process. Did you post any details about this issue in the support forums? If yes, please paste in any links and we'll be sure to check them out.
We'd also be interested in hearing more about your migration needs in the support forums. There are several improvements that we already have planned for the feature, but the more feedback we get on it, the better.
Thanks,
Matt
Matt,
Yes, both issues are being addressed by support. I will also post more details about migration issues. Thank you.
Matt,
what do you think of implementing release train model for a new hardware porting existing software from a different hardware architecture?
will the train model actually work?
thanks.
lou -- I've never done hardware development before so I'm not sure how well a release train applies. At the very least I'd imagine that you'd need slightly longer iterations?
I'd recommend to separate the porting layer from the apps layer. Your porting vendors drive your releases under the apps layer.
Ive implemented the release train myself, including the name! It worked only if you have a seamless migration and customers are TRUSTING your software. When you get more down the line the release gap between your current release and the environments in the field will become bigger. People will not migrate if they do not trust your software. Instead of migrating they will demand fixes in the release they have. In such a case you will have a deadlock. Mind you, this software is rapidly replacing the MS Office paradigm and only one glitch in a seamless migration will stall the IT depts. into further migrations.
We finally gave 2 flavours:
Get Fix Packs on a major release (including porting fixes)
Get a Release Train (a functionality migration!) from one to the next major release.
If Im gonna buy your software Id like to see those options.
http://www.accurev.com/product/docs/SCMBranchingModels1.pdf
What kind of branching model do you use? Branch by purpose or something else?
What SCM do you use if you don't mind saying?
How is it going in that dpt.?
Sounds like a good model to me.
Very Lean: http://www.poppendieck.com/