Firmware on SourceForge

I posted the latest compiled version of the firmware to sourceforge. i'm not really sure what the status on it is, but people were asking for it elsewhere on the forums.

simon, if you could verify that the version in svn is good to go, that would be great. also, there is a script in the firmware folder that creates the release .zip file automatically to make releases easier. if anyone makes changes to the firmware and wants a release, simply use that, or ping me and i can take care of it rather quickly.

also, i just chose 1.0 as a default starting point. let me know if its deserving of a different revision number.

I hacked two small but useful firmware-related things tonight, and both jinxed and sebastien tested them for me live on IRC. Those changes are checked into subversion.

(1) The building of SDCC now works without having to manually edit newcmdcl.h in the SDCC sources. So now, checking out the firmware subtree and doing a make in there "just works".

(2) I hacked slightly on Zach's package-release script so it defaults to using today's date as a version number (YYYYMMDD). So if you do

svn co [reprap.svn.sourceforge.net]
cd firmware
make
sh package-release

you end up with a file such as reprap-firmware-20070530.zip containing the .hex files that you just created. To make an "official" version just do

sh package-release 1.4 # Or whatever version you are releasing

This should make it a lot easier for people to generate the .hex files for themselves from now on :-)

Incidentally, I think that we should consider using YYYYMMDD style "versions" on .zip packages, until we make a formal release? It makes it clearer what people really have, when you ask them what they downloaded... does that make sense?

I'd like a dist target in the Makefile instead of the separate script... coming soon, maybe.

Jonathan

personally, i find date based number revisions to be very confusing. they dont tell you anything. on sourceforge, it already lists the date when a file was released, so all you know is that its there. the date files would be handy for sending .zips around to others for testing *before* making a release.

with a solid x.y.z number system, you get some implied things that are very useful. i'll go over these for those who may be unfamiliar. take for example v.1.2.3. the 3 numbers each have significance. these vary from project to project, but these are the ones i use and i propose we adopt project-wide.

1. is the major release number. all v1's should be compatible. if you break compatibility, then this number should increment.
2. is the minor release number. it gets incremented when a new feature or bug fix goes out. it should still maintain compatibility with previous versions.
3. is the revision number. it signifies very small changes, such as a simple bug, cosmetic changes, mess-ups, etc.

also note, that these are hierarchial. so that when you increment 1 to 2, then 2 and 3 would zero out. eg 1.2.3 => 2.0.0 (or just 2.0) or 1.2.3 -> 1.3

furthermore, when the project gets big enough, we could easily transition to the linux kernel style of versioning where even minor releases are 'stable' and good for use, whereas the 'odd' numbers are development versions. that seems like it might be a bit excessive for our use now, but its definitely something we could do.

Once a file is downloaded from SF and on an end user's PC, you can't "see" that SF date any more. Look at this from and end user viewpoint, not that of a core team person making releases. Maybe someone handed the user the files on a USB drive or a CD-R. Think about doing phone or IRC based tech support for (possibly hundreds or even thousands of) end users. Good, solid release engineering is a key part of making that even slightly feasible without drowning the team totally. Exponential growth can have its drawbacks :-)

My primary issue with the current approach is that right now, version numbers are all over the place. We're still very much in alpha test, in terms of system quality and degree of testing -- and there was a zip file with a 1.1.1 version up there on SF, for example. There doesn't seem to be much consistency to the current set of file names. Which is fine for now, and definitely better than requiring everyone to use svn (!), but bad for the long haul. Is there some kind of overall release planning document anywhere? What are the quality, packaging, functionality and documentation requirements for a real v1.0 release? For a 0.9? Should there be such a release plan document to guide us?

ZachHoeken Wrote:
-------------------------------------------------------
> ... the date files would be handy for sending
> .zips around to others for testing *before* making
> a release.

Yes. And that is *exactly* what is happening now... the .zips being posted are not "fully tested stable official releases", just early test versions to help people who can't handle the software development environment. Right? Maybe we are using the word "release" in different ways.

As I see it, the use of YYYYMMDD is a "for now" thing, until we have all our ducks in a row for a more formal (tested, documented, known working, replicable-by-a-mere-mortal) release. I'm not suggesting using YYYYMMDD forever, just for alpha quality quick "put something up to help a few people out" type of things and for personal/internal use.

I think 3 level X.Y.Z versions may be slight overkill, but I'm cool with it for "real" releases. Just not with semi-randomly generated numbers in there, which is what seems to be happening now :-)

Overall, I don't think the state of the system as a whole really warrants a 1.0 release yet. Wouldn't we need to convert the Wiki pages into actual documentation files in some appropriate form (DocBook? ODF?) and include those, for instance? How well documented is the host software from and end user perspective? How clear are the build instructions for each subassembly? Where is the list of required tools? Have all build instructions been tested by someone not on the core team, and edited to fix any difficulties found? I could go on ...

I think we could look at a 0.9 (or 0.8 maybe) release soon, if someone wants to write up a set of criteria for such a release as a short term target. It's probably time for all the "release lizards" to start working on some level of release engineering, as well as on the (more fun for many of us) deeper technical challenges of the project.

If this is all overkill and too much for the team to handle, tell me that and I'll lower my standards :-)

Jonathan

*If this is all overkill and too much for the team to handle, tell me that and I'll lower my standards :-)*

probably. right now, its basically just me doing releases. people were asking for them, so i put them out there. i think its commonly understood that we're a work in progress and that these files will change.

you are making very good points about this, and i probably jumped the gun by releasing them at >= v1.0. realistically, i should've released them as v0.1 or something and then bumped that up to v1.0 once we made it official. i just wanted a base to work from.

however, for certain things like the electronics, the versions are accurate. same for the firmware. the object files are also pretty accurate. the only one we dont have up realistically is the host software, which i would put at a 0.8/9. it definitely needs some work.

also, 'fully tested' is a bit vague. right now we're still working and finding out exactly what we need, so we dont have a goal to test for. we're basically testing as we go on. if we find a bug, and fix it then we will/should just release a new version.

i think our best bet would be to stick with what we have. if problems pop up, we fix them, and keep pushing forward. speaking of which, i think we should try to get a java package out soon. that is probably one of the more important packages.

I think that at some stage, this project is going to need to transition from pure research into a somewhat more conventional project, in the sense of packaging, support, documentation, ease of use, etc. I'd thought the start of that shift would be with the release of "RepRap Darwin v1.0"? But OK, if we're not ready or willing or able to do that, then we're not going to do that.

> 'fully tested' is a bit vague. right now we're still working and finding out
> exactly what we need, so we dont have a goal to test for.

That's why IMO a document stating the goals for each release would help... so we *do* have clear and specific goals to test for -- so we know when we have in fact reached "v1.0" level in each area, and can go ahead and release with some degree of confidence in our work :-)

Examples, so you can see a bit more of how I was thinking:

(1) One succinctly described overall functionality test is: Can the resulting assembled system can replicate each of the RP-able RepRap parts (well enough that the generated parts are usable to build another RepRap)?

(2) Tests for populated PCBs could be defined in terms of poke (or maybe better, poke under control of an expect script), as could tests for a full set of such PCBs all connected up in as a ring. Some tests might use the LED stepper substitute test boards, too and define the visual effect of certain pokes or sets of pokes.

(3) Tests for host software can be very generally described in terms of "Does it do what the manual says?"... once we have a user manual for the software :-) Without one, we'll need to define host software quality in terms of things like "does it run on computing platforms X, Y and Z?" "Does it talk to a set of tested electronics PCBs running version Q firmware sucessfully?" "Can it (virtually) build some specified small set of parts from a set of test .stl files using null cartesian?".

[There are other ways to go, perhaps involving simulating a set of electronics boards entirely on the host PC... then you can ask the host software to "print" to that simulated set of electronics, log the SNAP protocol dialogue that ensues, and compare that to a knwon good SNAP dialogue captured from a real live set of electronics... but that'd be a fairly significant (though useful) piece of work].

(4) I'm not a mechanics expert, not even a beginner really, so how you test and validate the mechanics independent of the full system is something I can't comment on. I'd hope there is some set of tests one could do on the 3d robot with no control system to check it out? And on an extruder, likewise.

(5) Tests for documentation can be defined in terms of both "are all major subsystems documented?", and "can the intended readership of these documents understand them, and are they understood in the same way by multiple different readers?" and so forth. I'm not a tech writer...

(6) Tests for firmware are awkward without a PIC simulator, but basically if electronics tests using poke "pass" one can perhaps assume the firmware must be doing its job somewhat adequately, I suspect?

I am concerned there could be significant negative publicity and negative feelings if parts kits are shipped and v1.x releases are released and, when multiple people each with moderate (but adequate) skills in soldering and mechanical assembly purchase and then assemble kits and run the software per the supplied documentation, the resulting systems do not do what they are supposed to do (or what they are expected by their owners to do). The only way to mitigate that risk is to test, in a somewhat well-defined fashion, prior to declaring "Release 1.0", isn't it?

Anyway, OK... based on your advice, for now I'll scale back my thinking on this whole "release engineering" area, at least for now, and just "package" some form of host software.

I hope having this sort of dialogue now isn't "just noise", even if we can't implement these ideas at this stage of project development. If I'm being noisy, forgive me, please! As you can tell, I'm still very much learning what the norms for this project are.

Thanks,

Jonathan

i definitely understand what you're feeling. you want this to be a success, and it will be! you're not being noisy, its just that we're not quite to the stage yet where it makes sense to setup strict testing guidelines. of course we will test, and make sure things work. when we make the next release, we will definitely want to test things better. as we continue on our RepRap journey, the testing will get more advanced and well defined. its just a natural progression.

for each area we should implement the testing that makes sense to do now, and put off the stuff that doesnt make sense. overall, the goal should be to improve the software and the project. also, it was hard to test stuff before. for example... with the software, nobody really had boards other than adrian. now that people have boards, we have a much wider audience to test the software.

also, anyone working on the project at this stage should have a full understanding that they are acting as developers and beta testers. if they dont, we should make that more clear.

> anyone working on the project at this stage should have a full
> understanding that they are acting as developers and beta testers

Sure. At *this* stage! But when you call something "v1.0" -- people will not expect that so much any more. Publicity from a "v1.0" release will bring in many new onlookers, all potential new reprappers. And, I think, we've been suggesting that "v1.0" is "just a few weeks" away? So, on that basis, I thought we were now gearing up for the shift to formal releases.

> ... we're not quite to the stage yet where it makes sense to setup
> strict testing guidelines...

How "strict" the tests are is definitely totally open from my perspective -- I just think there should be *something* to measure each major subsystem, and the "whole system", against. In fact, making the planned set of tests for "v1.0" public ahead of release, and soliciting feedback on them, could help in setting user expectations for that release.

It sounds to me as though you are seeing "v1.0" as being what most people would call a "public beta" ... along the lines of "it might work, you are likely to find bugs and issues, it probably won't let you get anything real done, but please tell us how it goes" expectations. In my mind, "v1.0" is associated with a higher level of "working-ness" than that. As long as I'm peculiar (very probable!) and other potential Reprap-builders don't have my expectation or understanding of what "v1.0" means, all is well.

Jonathan

I think we're conflating two distinct things here:

1. How to number files, and
2. What constitutes a release, and when do we have one.

The only intersection between these otherwise distinct questions is when a numbering system implies to the world that we've made a release when we haven't. The problem is that a proper numbering system is both the best way for us to handle things internally pre-release and (unless we start numbering files -2.-5.-4...) implies to the world that there's a V1.2 (o.w.e.).

I propose that we ignore implications. We'll announce a release when we have one. If people infer that we've made one when we haven't because of some file numbers, then that's a little regrettable, but no real harm is done.

I don't want to sound like Compton Compromise here, but can't we have both a date and the major/minor/revision thing? So files are called zippo-clamp-archive-1.2.5-2007-05-13.tgz

Or is that a bit of a handful?

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Jonathan - I want to make a change to the firmware. I wish to add another extruder (for support material); it'll start identical to the one that's there but with an address of 9. It will then diverge as I edit the code. But I don't want to tread on what you're doing, so if you could do the file copies - extruder1.c and extruder2.c (the .h file should stay the same) - and Makefile edit, then check the result back in, I'll take it from there.

Let me know.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

> The only intersection between these otherwise
> distinct questions is when a numbering system
> implies to the world that we've made a release
> when we haven't.

The piece of SourceForge where you make files available for download is called the "File Release System"... when you stick package files there, in one sense you have "released" those files. Ready or not, tested or not... they just got "released"! So if they have numbers like 1.1.1 in them, we just "made" a version 1.1.1 release of that package, as far as anyone visiting SourceForge is concerned. If files are labelled more like 0.1alpha4 or 20070601, most of the open source world will, I suggest, tend to understand that this is not a full "real" release.

How the version numbers of sub-packages can or should relate to the "overall" version number of the whole thing is another sub-component of release planning yet to be discussed, as far as I know. I have ideas on that... but they can wait.

> The problem is that a proper
> numbering system is both the best way for us to
> handle things internally pre-release and (unless
> we start numbering files -2.-5.-4...) implies to
> the world that there's a V1.2 (o.w.e.).

Not really true, if we use low 0.x version numbers, or use dated files, during alpha testing. Again, by convention as well as in most number systems based on Arabic numerals (!), 0.x means "something lower than 1.0", since 0 < 1 -- there is no need to use negative numbers to achieve this. Similarly, using a YYYYMMDD date doesn't even look like a "real" version number. Therefore, releasing 0.x.y or 20070601 does not at all imply there is a 1.2 (or even a 1.0) yet.

> I propose that we ignore implications.

Your call completely, but IMO this is totally unnecessary, given the existence of the cipher zero and how its use in the major version number position is generally understood :-) How does ignoring established convention (in this regard) help the project? How does it benefit us to "ignore implications" like this?

> ... can't we have both a date and the
> major/minor/revision thing?

Yes, but once releases are "real" (major version >= 1) the dates are not all that useful any more (except on internal test stuff that probably shouldn't be going into the public SF File Release System at that point anyway!)

> Or is that a bit of a handful?

IMO, yes :-)

I propose that anyone putting files into the SourceForge "File Release System", should avoid using version numbers other than dates, 0.x, or 0.x.y (where x and y are base ten digits 0 through 9, in case that's not clear) unless the file(s) concerned truly are official tested releases and there is at minimum some sort of prior agreement that they are appropriate for public release (and related subsequent future tech support by the RepRap team, and everything else a public release means for a FOSS project).

I don't know whether the "subsystem X is good enough to be called 1.0" decision is Adrian's, or voted on, or what... (that is a separate issue) but IMO there should *be* some sort of decision process for that, and developers should know what that process is :-)

IMO again, it would be clearer and more open, and also helpful to developers and packagers, if we had at least some rough written guidelines of expected performance for each subsystem, to help in making those release decisions, but (per Zach) we're not ready to attempt that yet.

I hope it's OK to discuss this kind of "project process" stuff in public like this... if not, let me know :-) It's probably more important that we *have* an understood release process, than that it follow any particular model or approach!

Bottom Line: Can we stay away from 1.x and 1.x.y numbers in package files for now please, and can we also take the discussion up a level, so we are talking more about overall release process than about one (minor?? or maybe not so minor) aspect of it?

Thanks,

Jonathan

***I propose that anyone putting files into the SourceForge "File Release System", should avoid using version numbers other than dates, 0.x, or 0.x.y (where x and y are base ten digits 0 through 9, in case that's not clear) unless the file(s) concerned truly are official tested releases and there is at minimum some sort of prior agreement that they are appropriate for public release (and related subsequent future tech support by the RepRap team, and everything else a public release means for a FOSS project). ***

That sounds fine to me.

***I don't know whether the "subsystem X is good enough to be called 1.0" decision is Adrian's, or voted on, or what... (that is a separate issue) but IMO there should *be* some sort of decision process for that, and developers should know what that process is :-)***

I don't know either :-) No - what's been happening so far is that I've been flagging bits and pieces as frozen at [reprap.org] when they work. It's more important to make bits that don't work work (there aren't many of them) than to make bits that work work better.

***I hope it's OK to discuss this kind of "project process" stuff in public like this... if not, let me know :-) It's probably more important that we *have* an understood release process, than that it follow any particular model or approach!***

Yes - that's fine; file naming and release are technical issues. That's what the forums are for.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Now that we're getting more people into the effort it might well be time to appoint somebody to head a small team to pick through all of the improvements that RepRappers make on the software during a given time frame and assemble, test and Q/A each new general release.

That's a big job.