keighrim
commented
6 months ago If you meant GH's fork feature, I don't think the forking feature is not designed for this usage. Besides, what's proposed can be achieved with pure git branches with much less complication.
But in any case, I don't think having parallel versions of different versions is not the way I want to move forward, since I don't want anyone on the team to pay the cost of maintaining such noodled codebase (I have done a lot of that during our LAPPS days and it wasn't just not fun, but utterly unsustainable).
If we really want to separate models from apps, I believe the only sustainable way to do that is by creating a model directory in addition to the app directory. However, given the scale of our project, I don't think that worth investing our development time either.
Given that, for the time being, the most viable option is probably keep the "linear versioning" practice, while shipping the "models" altogether with codebase (or packaged in the container image). And that's is what's done in v4.1.
(originally posted on app-swt-detection then transferred here)
Because
I feel there may already be an issue or discussion about this somewhere but I cannot find it so starting this new one for now to dump some thoughts. This was prompted by (i) previous unresolved discussions, (ii) @owencking's request to have a fast bars application asap, which I think @keighrim has started by generating a new fast model, and (iii) some ongoing discussions in clamsproject/app-swt-detection#60.
All the code needed to create a fastbar app is in this repository. Maybe at some point we have generic code in the SDK to create classifiers, but we do not have that luxury now, so the most likely place to release a fastbar app is this repository. The problem is that up-to-now we have a linear versioning approach where new versions are built on top of old versions. And if we want to release a new SWT app for fast barring, then we would make it version 4.1 or 5.0 and continue development from there.
I do not particularly like the thing I am going to propose now, and I see it as a stop-gap solution at best, but what if we allow forks in the repository. For fastbar, we would fork-off from 3.0 or 4.0 and create 3.0.fastbar and the only change would be the model shipped with that version and possibly some configuration settings. This would not scale up because we don't want to create those forks any time we have a new version release.
An alternative is to fork the entire repository just to spit out a one-off app, can't say I like that too much either.
Some related thoughts:
Finally, I realize that this repository may not be the best place to start this issue since the problem is more general.
Done when
No response
Additional context
No response