Timeline for In git, how to do versioning for a dozen libraries all worked at in parallel
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 25, 2015 at 7:45 | comment | added | sbi | @Patrick: And again no argument on the subject. HAND. | |
| Jun 23, 2015 at 12:44 | comment | added | Patrick | @sbi I don't know why you're being so antagonistic. I provided an answer to your question that I thought resolved your issue. You obviously disagree, let it go | |
| Jun 23, 2015 at 9:22 | comment | added | sbi | @Patrick: I have described the steps in my question, and not only is the turnaround non-zero, it's also rather big. You, OTOH, haven't even bothered to provide an argument for why that seems neglectable to you. | |
| Jun 19, 2015 at 18:27 | comment | added | Patrick | sbi the turnaround time for the process @arnaud suggested is essentially zero. Since all current projects have a particular version they are dependent on, they should always pull from that repo at that version number, if you push a new commit to master on that repo, it should be tagged with a new version number. | |
| Jun 16, 2015 at 16:15 | comment | added | sbi | @arnaud: Maven is something in the Java world, while we're in C++ land. (I'm not saying it wouldn't work for us, only that we don't know it.) | |
| Jun 16, 2015 at 16:14 | comment | added | sbi | @arnaud: The turnaround times for such a process for (currently rather common) changes cutting through three or more layers would kill us. I thought my question described that. | |
| Jun 16, 2015 at 14:48 | comment | added | dagnelies | @sbi: so what is exactly your issue? You make your changes, bump the version, update dependencies where required, and voila. What you described in your initial post is typical maven & co. stuff. Each distribution is based on clearly defined versionned libs. How could it be more clear? | |
| Jun 10, 2015 at 20:43 | comment | added | sbi | Again, declaring dependencies is not our problem. We can do this already. The problem is how to manage changes cutting across several projects/libraries in an efficient manner. Your answer fails to explain this. | |
| Jun 10, 2015 at 20:06 | comment | added | Patrick | @sbi This would manage the overhead of creating new versions and maintaining stable project releases. Since you can dictate that project x relies on project y version 2.1.1, you can create new versions of project y that would not affect project x. | |
| Jun 10, 2015 at 18:04 | comment | added | sbi | But dependency management is not our problem, this is solved. We currently regularly make changes across many libraries and need to minimize the overhead of creating new versions while maintaining stable project releases. Your answer doesn't seem to provide a solution to this. | |
| Jun 10, 2015 at 18:01 | history | answered | Patrick | CC BY-SA 3.0 |