search

rdagumampan / yuniql

Free and open source schema versioning and database migration made natively with .NET/6. NEW THIS MAY 2022! v1.3.15 released!
https://yuniql.io
Apache License 2.0
417 stars 63 forks source link

Support _draft folder at version level #288

Open filipe202 opened 1 year ago

filipe202 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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