Wouter van Ooijen wrote:
> > I like to be able to edit
>> these library source files (refactoring, adding new functions) as I'm
>> working on a project that is using those libs.
>>
>> To make things even more complicated, how do you avoid breaking old 
>> projects
>> when you, for example, add parameters to a function? Is there a way to 
>> make
>> a "snapshot" of a project, given that my_uart, my_leds, and
>> my_uart_led_blinker each live in their own repositories?
>
> These two aims do not combine. Most projects I knew freeze the project,
> sometimes including compilers, OS, and hardware, once a project is
> delivered. Migrating to a new OS, compiler, or library is handled as a
> very big change, including full re-tests. Even (or maybe especially)
> when the author of the library claims that the only change is a few bug
> fixes and additional functions.
>
> In the development phase things can be more fluent, often only the
> project source is routinely saved, and in a large project (many persons)
> there might be a separation between the latest version of your code (on
> which you are working) and the version of your code that others use to
> test theirs.
>
> But I have never seen nor have I been able to come up with a good
> combination of updating existing projects (gee, this bugfix in the libs
> must be distributed to all our projects. Let's re-test the space shuttle
> !) and reliability/predictability (gee, yesterday the
> rudder/airelon/whatever behaved differently, now I can't get the plane
> out of this stall. Houston, what did they change? Oh, just a routine
> bugfix update).

I don't like your answer, Wouter! Can I please get a second opinion? :-)

What do you do when you want to reuse code that you've written? Copy/modify? 
We've all done it, but it feels so wrong...

Spending the time upfront to make the interfaces between the modules rock 
solid, and keeping the number of "connecting points" to a minimum sounds 
like the perfect solution, but it goes against the Agile programming 
principles that I've come to know and love... in fact, I found that combing 
through the same piece of code repeatedly is often the only way for me to 
end up with what I would consider "good code". Defining interfaces in detail 
upfront is yuky, because it forces me to make decisions early, and base them 
on limited information...

Brook's "thought stuff" is actually very sticky...

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist