S
Simon L. Prinsloo
Guest
First off, I am very excited about this change. However, taking a closer look, it appears that this change is going to seriously disrupt my ability to push my customers into faster upgrades, because it seems to embed version specific information into the workspace now. It also seriously disrupts my ability to participate in the CVP due to the fact that I now have disruptive configuration in the project space. The project/source control environment needs to be version agnostic (or at least should be able to) and should get that type of information from somewhere else, where it can be configured once. And PLEASE, no environment variables! (Unless maybe if they can be defined on the workspace level.) For advocates of the newest releases like me, it is of cardinal importance that the tooling gets its version specific information from the workspace and not the project. In other words, I need to be able to override project specific settings like these outside the source controlled environment, or we risk disrupting entire development teams. I would have no problem with keeping a small, custom, version specific project in each workspace where I can keep overrides for these files without disrupting the project for those with no overrides. In fact, where ever I had a say in the design, the build pipelines and configuration always lives in a separate (general, non-OpenEdge) project which quickly stabilize once a version change is adopted. Branching that is normally risk free, because none of its content is intermingled with the day-to-day work being performed. When I get a preview release or a new version. I set up new work spaces but I import the existing projects. That way I can work and test on the new version while keeping my delivery commitments. When I find any problems, I can easily switch between the work spaces, with the only drawback that I need to do a full build between the versions. This makes it easy to confirm if a problem exists on both versions, if a newer version introduce regression or if a newer version fixed a problem. It also makes it easy to demonstrate cool enhancements in a newer release version to my fellow developers on their own code base, providing practical use cases that are used to increase pressure on their management to upgrade. The build pipelines, being configured for the correct release, catch me out if I inadvertently use new functionality that is not compatible with the older versions. After a while, I start pushing for the use of the new version actively. When people have doubts about compatibility and stability, I normally point out that I have been coding and dev testing on the new version since its release already and that much of that code is in production. Bonus for them is that I normally already branched and adapted the build project at no cost to them. 
Continue reading...
Continue reading...