Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

13
  • 1
    Changing your tooling shouldn't affect the processes you have in place too much. So, how were you dealing with this problem before you switched to git? Commented Jun 10, 2015 at 15:39
  • Is it possible to simply add a new method to the interface without breaking the existing one when too many libraries depend on it? Normally that's not the best idea but at least it would let you "get on with" implementing the new feature and you can properly deprecate the old method whenever there's a spare moment. Or are these interfaces too stateful for "parallel interfaces" like that to work? Commented Jun 10, 2015 at 15:41
  • 1
    @Ixrec: I was told that "this is not the git way" of doing things. Everybody uses individual repositories for individual projects, so it was decided we do that, too. Commented Jun 10, 2015 at 15:45
  • 2
    I would argue they are not separate projects if they frequently have to be changed in tandem. The boundaries between "projects" should always have some kind of long-term backwards compatibility guarantee imo. Commented Jun 10, 2015 at 15:48
  • 1
    @Ixrec: Integrating more hardware is similar to porting code to more platforms: the more you have done this, the less you need to change for yet another hardware/platform. So in the long run, the code will stabilize. However, right now we will need to find a process that allows us to stay in the market long enough to get there. Commented Jun 10, 2015 at 15:51