Hi Nathan,
I am very glad for your reply and at the same time, super-excited :) As I wrote before, we share the same thought that having two separate projects is a waste of time and energy, so I would be very happy if we can merge the trees again.
Currently, my primary concern is that I have an urgent (or, more frankly, _critical_) need for a new, stable version of the 3.x.x tree that includes as many bug fixes and low-risk new features as possible (esp. in the Oracle department). I will take a look at LB4 when I get the time, but from my "gut feeling", I do not think that the 3.x architecture is a dead end; the only thing that could get problematic is that Database and Connection classes are very closely coupled and that it might be difficult to get multi-connection support working with their current structure, but that really is the only architectural road blocker I have encountered so far. I really like the code base, you have done tremendous work!
So, this is what I will try to do:
- Until we find a way to merge the code base, I will try my best not to introduce any incompatibilities. However, some of the PRs I have already integrated need changes for the upcoming dbchangelog-3.6.xsd file. To prevent namespace pollution, I will make a separate XML namespace for anything that is incompatible with dbchangelog-3.5.xsd and earlier.
If you agree, may I ask you to monitor my copy of the the schema and contact me ASAP if you see something that you cannot / don't want to merge?
- To keep everything as neutral as possible, I will make a constant somewhere so that as few "DB-Manul" strings as possible as present. That should make merging easier. The problem is that I already have put in a lot of hours, so it is next to impossible to extract everything I have done so far into "neat" PRs.
- Due to the urgency of a new version in the commercial software project I am working in, I will need to keep my fork alive until we find a way to merge it. However, feel free to cherry-pick anything from my tree that you find interesting.
For your convenience, you will find three files in the root directory of my tree:
- pr_mapping_with_upstream.txt: Shows which PRs from the liquibase tree I have already integrated into my tree. The numbers there should be easy to find in the git logs (try searching for something like pr#999). Feel free to cherry-pick if it helps you getting through the PR queue quicker.
- bug_mapping_with_upstream is a cross-reference to the Liquibase Jira tracker which shows the CORE-xxxx numbers that I might have already fixed in my tree. Maybe it can help you get through the JIRA list faster.
- RELEASE_NOTES_0.1.txt - this is a longer, more verbose form (essentially a git log made for end-users). If you want an overview of the changes, this might be helpful.
A few ideas:
- I have working integration tests for OSS databases (using CircleCI, I had problems getting TravisCI to work in the way I needed) except Firebird SQL (some showstoppers there). It includes several bugfixes for closed-source DBMS like Oracle and Sybase / SAP SQL Anywhere / IBM DB2 as well. Use / copy that if you like.
- There is a SONAR cloud service which I use in trying to improve general code quality. The rule set I use is very strict (due to the horrors I have seen in commercial software development![]()
) - maybe this is something you would like to use as well?
Last thing, may I ask if you have an estimate on when you can spent time on Liquibase again? At the moment, I am sort of a "lonely warrior" and working together on something is just more fun :)
All the best from Germany,
Andreas
I am very glad for your reply and at the same time, super-excited :) As I wrote before, we share the same thought that having two separate projects is a waste of time and energy, so I would be very happy if we can merge the trees again.
Currently, my primary concern is that I have an urgent (or, more frankly, _critical_) need for a new, stable version of the 3.x.x tree that includes as many bug fixes and low-risk new features as possible (esp. in the Oracle department). I will take a look at LB4 when I get the time, but from my "gut feeling", I do not think that the 3.x architecture is a dead end; the only thing that could get problematic is that Database and Connection classes are very closely coupled and that it might be difficult to get multi-connection support working with their current structure, but that really is the only architectural road blocker I have encountered so far. I really like the code base, you have done tremendous work!
So, this is what I will try to do:
- Until we find a way to merge the code base, I will try my best not to introduce any incompatibilities. However, some of the PRs I have already integrated need changes for the upcoming dbchangelog-3.6.xsd file. To prevent namespace pollution, I will make a separate XML namespace for anything that is incompatible with dbchangelog-3.5.xsd and earlier.
If you agree, may I ask you to monitor my copy of the the schema and contact me ASAP if you see something that you cannot / don't want to merge?
- To keep everything as neutral as possible, I will make a constant somewhere so that as few "DB-Manul" strings as possible as present. That should make merging easier. The problem is that I already have put in a lot of hours, so it is next to impossible to extract everything I have done so far into "neat" PRs.
- Due to the urgency of a new version in the commercial software project I am working in, I will need to keep my fork alive until we find a way to merge it. However, feel free to cherry-pick anything from my tree that you find interesting.
For your convenience, you will find three files in the root directory of my tree:
- pr_mapping_with_upstream.txt: Shows which PRs from the liquibase tree I have already integrated into my tree. The numbers there should be easy to find in the git logs (try searching for something like pr#999). Feel free to cherry-pick if it helps you getting through the PR queue quicker.
- bug_mapping_with_upstream is a cross-reference to the Liquibase Jira tracker which shows the CORE-xxxx numbers that I might have already fixed in my tree. Maybe it can help you get through the JIRA list faster.
- RELEASE_NOTES_0.1.txt - this is a longer, more verbose form (essentially a git log made for end-users). If you want an overview of the changes, this might be helpful.
A few ideas:
- I have working integration tests for OSS databases (using CircleCI, I had problems getting TravisCI to work in the way I needed) except Firebird SQL (some showstoppers there). It includes several bugfixes for closed-source DBMS like Oracle and Sybase / SAP SQL Anywhere / IBM DB2 as well. Use / copy that if you like.
- There is a SONAR cloud service which I use in trying to improve general code quality. The rule set I use is very strict (due to the horrors I have seen in commercial software development
) - maybe this is something you would like to use as well?Last thing, may I ask if you have an estimate on when you can spent time on Liquibase again? At the moment, I am sort of a "lonely warrior" and working together on something is just more fun :)
All the best from Germany,
Andreas