Combined pull requests (status, BOM handling, sequential ordering, version conflict detection, etc) #28
Conversation
* SCM coordinates * issue management * CI Management * distribution management
…efault for all of the templates. Now both "--//" and "-- //" are acceptable. "-- //" is a more standard way to use comments in standard sql. Now editors should not complain about our marker comments.
And add badges
Add some text in the status description field to indicate if a script file is not found in the file system. This can happen, for example, when running status on a database when the local environment is on a branch that does not include one of the migrations previously applied to the database.
… its state does not affect other tests
…ile for the command object
…ts with a miss formatted number
…ion to the New command to support testing and add to functionality
…requiring a ticket number)
… pattern Added sequence number padding configuration option.
|
@Mazrick Can you rebase and squash your commits? |
|
@Mazrick , Thank you for your contribution! Please use the GitHub's reaction feature to up/down vote the PRs instead. |
|
@harawata I tend to agree with you, but we are forced to do things we don't really like to when the maintainer lag is literally Mar 9, 2015 - Apr, 9, 2016. |
|
We are trying to improve our support so lagging goes away. If you can get us something it will see a release very soon. Sent from Outlook Mobile On Thu, Apr 21, 2016 at 9:25 AM -0700, "Crispin Botticelli" [email protected] wrote: @harawata I tend to agree with you, but we are forced to do things we don't really like to when the maintainer lag is literally Mar 9, 2015 - Apr, 9, 2016. You are receiving this because you commented. |
|
@Mazrick considering how much you have paid for the tool I suppose you can imagine that we work here in our spare time and just for fun so I am also sorry for the lag but this is how ths works. |
|
@emacarron, I totally appreciate the effort you guys have put into this tool! It does a lot of what I needed in a very straight forward way! At this point development has diverged a bit, as evidenced by the fact that some of the fixes and merges are built upon each other, and some of the code was merged into the base and some of my changes are not. So I'm thinking about separating them into staged pull requests that build on each other. I'll endeavor to submit only one PR at a time, then only after it is accepted, I'll submit the next, if it does indeed build on the previous steps. Thank You! |
I wanted all of the features available in the pull requests:
So, I started from the most current master, and merged those pulls into this branch.
I also:
I have fully tested locally with updated unit tests.
There were some dependency changes made to the pom.xml on some of the pull requests, which I am not fully informed about, so if there are any pieces which should first be reverted or changed, please feel free to comment and enlighten me!