By Alex Luyando - 2/4/2009
Hi all -
I've read many postings about how stable the StrataFrame betas are and how MicroFour uses the betas when working on their production medical software before the betas even get posted for the rest of us. From the little experience I've had thus far with the betas they certainly do appear stable and perform as advertised.
Still, I'd like to see some comments from folks both in and out of MF regarding how quickly or slowly everyone installs the betas. Among the questions/thoughts I have are the following, although please do not limit the discussion to just these topics.
- For those in a multi-developer shop supporting internal applications, what are the benefits and risks of early use of SF betas?
- In the above environment, how do people handle situations where you've updated to a SF beta, and then need to get a production patch out? Do you maintain a separate development environment with the prior (perhaps production) StrataFrame release to handle production bug fixes?
- For the early adapters among us, has there been "gotchas" from time-to-time that made the early installation of the betas less than ideal.
- For the early adapters among us, has there been times where it turned out to be significantly better to have installed the beta as it resolved some prior bug or provided improved functionality that significantly reduced development time?
I think our shop needs to determine a policy for all StrataFrame developers to either upgrade to the latest beta pretty much as they come out, or just stick to "production" StrataFrame releases. This has been sparked by what I believe to be the well-documented change to the BOs FieldPropertyDescriptors which seems to cause an application we have to work on one developer's workstation but not the other. Either way, we need to pretty much march to the beat of the same drummer so comments on the above will be helpful, I'm sure.
Thanks.
________________
_____/ Regards,
____/ al
|
By Aaron Young - 2/4/2009
Hi Alex,I always install the betas as soon as I see them. In fact the first thing I look for in the forums is a new beta release  To be honest, I don't really consider them as "betas" as they are reliable. Aaron
|
By Geoff Hirst - 2/5/2009
Hi Guys,I have to concur with Aaron here, I'm a sucker for a new beta and pretty much drop it in there as soon as the SF guys make it available. Sometimes you come across a crab, but very rarely. cheers G.
|
By Keith Chisarik - 2/6/2009
I run on the most current "release" version unless I have a specific reason to install a beta. I did use to install beta's the day they were released and nothing bad every happened from it.I just had one too many person raise an eyebrow at me when I told them to install a beta.
|
By Alex Luyando - 2/6/2009
I just had one too many person raise an eyebrow at me when I told them to install a beta.
LOL That I can related to!
Thanks all... would still like to hear from others both in and out of MF...
|
By Trent L. Taylor - 2/6/2009
When we post a beta we beleive that it is ready for production minus the documentation and the samples being updated. As you can see, we do try to keep the StrataFlix sample up to date even during betas as this is a core tool used by developers getting started as well as working through issues on the forum.It is generally my recommendation to load betas. If there is a "show-stopper" then we try and stop what we are doing to get these types of things fixed. If it is something that doesn't make things "shut down" then we will get it fixed and post a build as soon as we can. In truth, developers who load the betas generally get more of what they want in the framework because it is more fluid and they see things as they come out and make recommendations. When we are in a production mode, and these types of recommendations come out and work into the flow of our postings, then it makes it easier to pop in there and add some features and enhancements versus posting a request and then waiting for the next cycle. Whether we post a beta or a final release, there is obviously no guarantee of not having a bug or issue. But it is our policy and desire to make sure that our users are not put on a island or left stranded when trying to get a build out the door. Finally, when loading an update in a development shop all working on the same project, then everyone need to be on the same page. Either everyone needs to load the build or wait for the final release. Working with two different versions will cause an issue. Just like Alex mention in regards to the field property descriptors in the latest beta. That is why we put great big letters in red on the post build warning of the update. Hope this helps.
|
By Greg McGuffey - 2/6/2009
I generally run with the Betas. However, I've been thinking about what might be a couple of gotchas related to versioning in general though:
First, since the SF DLLs get installed to the GAC, once upgraded, if you checkout your production branch to do a hot fix, I think your going to get the latest SF DLLs, as VS pulls from the GAC first. So, while your hot fix might be just updating a single method to fix some logic, you might suddenly be updating much more than that (e.g. rebuilding all your BOs).
Second, and related to the first item, if they update the RBS db schema, then again doing a hot fix for production would require updating the security tables. Using the DDT, this is pretty painless.
Third, if they updated ES, again you might have to update ES. This typically means unzipping the new files on the server, so again pretty painless.
So, the first is the one that concerns me the most, since it seems hard to easily reproduce an older version. I think you'd have to have the SF source as part of your source tree, so you always have the version of SF synched in source with any specific version of the product. If you needed to get back to exactly that version, you'd likely need to uninstall SF, then build SF from the source, letting it put the DLLs in the GAC and I think you'd be good to go. I'm still not a 100% clear on how the whole .NET versioning thing works, so it might be better or worse than this... 
Now, if for any product, your user base is keeping updated with the latest versions you release and you don't need to support older versions, I doubt any of these will ever be a problem (or very much of one). However, I wonder about the consultant that might have to support a SF 1.6.6 version of their app five years from now.
Again, none of these are really specific to beta, but more to versioning in general. Any thoughts on this?
|
By Alex Luyando - 2/6/2009
Greg McGuffey (02/06/2009)
I generally run with the Betas. However, I've been thinking about what might be a couple of gotchas related to versioning in general though:
First, since the SF DLLs get installed to the GAC, once upgraded, if you checkout your production branch to do a hot fix, I think your going to get the latest SF DLLs, as VS pulls from the GAC first. So, while your hot fix might be just updating a single method to fix some logic, you might suddenly be updating much more than that (e.g. rebuilding all your BOs).
I have to agree with this being a fairly significant concern, or at least something deserving clear-heading thinking. I tend to prefer to load the betas as they come out for lots of the reasons already mentioned here, but I do want to be able to produce hot fixes as needed.
To that end I am actually considering the benefits of migrating my development environment to a Virtual PC. I can then copy the virtual machine after a build is released to users, and even commit it to source control. In turn, this will give me a way of getting back to the complete and exact development environment--including SF release--that was in place when a production build was released to users.
Thoughts on this approach?
|
|