Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support _draft folder at version level #288

Open
filipe202 opened this issue Dec 19, 2022 · 2 comments
Open

Support _draft folder at version level #288

filipe202 opened this issue Dec 19, 2022 · 2 comments

Comments

@filipe202
Copy link

We would like to have the possibility to define a draft folder for each version as in our product sometimes we need to include new functionality in older versions and to do so with your current functionality we have a token with the target version and a draft sql file for each version with an IF at the beginning.

Thank you very much

@rdagumampan
Copy link
Owner

Hi @filipe202 , thanks for reaching out and for sharing your ways of working with yuniql. It's always inspiring to see how our users find creative ways to make things work :) yuniql was built on principle of immutable versions where each when committed can only be changed with another commit. This ensures repeatability and full history of the schema evolution.

To best understand your use case, can you please describe how your products and version is organized. Maybe you can be this on excel as I find this use case unique. Thanks. Br, Rodel

@filipe202
Copy link
Author

Thank you very much for your response.
We are a product with more than 20 years of development by a team of 10 people so as you may imagine it is quite complex
Our versions are organized using 4 version numbers:
vMajor.Minor.Build.Patch
We increase the Major version when there is significant changes in the product (e.g. a completely new front-end) and the Minor version when there is a bunch of new functionality to be added but not a revolution
Until here there is no problem if only added functionality to the latest version.
The problem is that we have hundreds of clients who have their own installation of our product on-prem and upgrading them all is impossible due many reasons such as contract, no time to train the users for the new version and third party applications that need to be rewritten in some cases. These reasons lead to the need of sometimes implement new features in old versions as the impact of forcing clients to update to the latest version is overwhelming.
Said so we are right now preparing version 8.0 and we have clients who are still using version 5.3 which was launched for the first time in 2013.
Hope my explanation is clear enough.
Thanks, Filipe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants