Ts-jest: Guidelines for collaborators

Created on 17 Jul 2017 · 6Comments · Source: kulshekhar/ts-jest

I'm creating this issue to discuss the processes we should put in place for us collaborators. Now that there are a few of us, it makes sense to document how we should handle things like:

merges
releases
other things (suggestions welcome)

This would go some way in making these things consistent regardless of which collaborator does it.

@GeeWee @bcruddy @morajabi

Source

kulshekhar

👍1

Most helpful comment

I'm a big fan of a the "+2" merge model.

This sounds good. I'd modify this to '+2' or x days, whichever happens first so that a PR doesn't remain hanging if some collaborators are busy.

I also think squash and merge leads to a cleaner git history but that's really just a personal preference.

I recall liking this suggestion when you (or someone else) had suggested this earlier, in another issue/PR. A change of habit required here but it is probably worth it.

I like the current approach of staying in line with jest's release versions but it may not be practical to keep up with patch versions as they may be fixing a bug we don't need to worry about or adding documentation.

I agree. Only the major (and minor?) versions should correspond to that in jest. The patch versions should be allowed to be out of sync since bug fixes in ts-jest don't depend on those in jest

kulshekhar on 18 Jul 2017

👍2

All 6 comments

I'm a big fan of a the "+2" merge model. First reviewer approves, second reviewer approves and merges. For some things its unnecessary but for code/behavior changes I think it's a good approach and generally leads to less reverts.

I also think squash and merge leads to a cleaner git history but that's really just a personal preference.

I like the current approach of staying in line with jest's release versions but it may not be practical to keep up with patch versions as they may be fixing a bug we don't need to worry about or adding documentation.

bcruddy on 18 Jul 2017

I'm a big fan of a the "+2" merge model.

This sounds good. I'd modify this to '+2' or x days, whichever happens first so that a PR doesn't remain hanging if some collaborators are busy.

I also think squash and merge leads to a cleaner git history but that's really just a personal preference.

I recall liking this suggestion when you (or someone else) had suggested this earlier, in another issue/PR. A change of habit required here but it is probably worth it.

I like the current approach of staying in line with jest's release versions but it may not be practical to keep up with patch versions as they may be fixing a bug we don't need to worry about or adding documentation.

I agree. Only the major (and minor?) versions should correspond to that in jest. The patch versions should be allowed to be out of sync since bug fixes in ts-jest don't depend on those in jest

kulshekhar on 18 Jul 2017

👍2

I'd be comfortable saying ts-jest MUST match major versions of jest. I don't really have an opinion on minor versions, and patch versions are not required at all to match.

bcruddy on 18 Jul 2017

👍1

I suggest to update the top comment with these new agreements.