Closed joewheaton closed 3 years ago
@joewheaton we do technically have the ability to have different versions of the business logic that trace legacy projects.
Eventually (and probably soon-ish) that may be a consideration. For now though it balloons the amount of XML we're responsible for.
For instance we'd need to think like this:
"Version 1.0 of the businesslogic is compatible with VBETs 1.0.1 --> 1.2.1 but 1.3 of the businesslogic is compatible with VBET > 1.2.1 until the next version comes out"
Now multiply that complexity across all our projects. We get around this in brat by having pyBRAT be a totally different project type than sqlBRAT.
I'm not sure what the strategy needs to be here I just want us all to be aware what's involved.
Understood... For now, this is an easy fix I suspect. Just do pyVBET and VBET. I don't think we want to have version-by-version differences we're responsible for. I do think though we can maintain different ones for totally different grades (e.g. research grade vs production grade).
I don't think there's any specific action needed here so I'm closing this. Re-open if I'm wrong.
@MattReimer and @philipbaileynar, this is a problem for which I have a specific work around, but we should be aware that this happening and figure out a strategy to avoid it going forward.
If one follows these instructions I made last Spring with RAVE 2.1 and downloads this old VBET 1.0 project for Middle Bear, it doesn't work. See here for demo:
The basic problem is that we are sloppy with our
<ProjectType>
tags (in this example<ProjectType>VBET</ProjectType>
) and not respecting the ability to maintain production grade projects and our research grade project tags concurrently. I know that you may feel like you only ever want to show the latest greatest. However, the real value in the warehouse is in a repository of older projects in addition to newer ones.