On Mon, Feb 4, 2013, at 09:43 AM, Michael Haberler wrote: > > Am 04.02.2013 um 14:11 schrieb EBo:
> > So my question to you is how long do you keep the 2.5 branch if/when a > > 3.0 branch becomes stable and fully functional? It should not be 0, but > > it also should not be forever. > > I dont know. I would think the 2.5 branch is a maintenance-only thing, but the > things that are added to it arent consistent with that. I cannot discern any > communicated policies. Clearly there are lots of un-communicated policies > around. I think the policy is that changes within a major version should either be bugfixes or improvements that don't break existing configurations. In other words, if a user updates from 2.5.2 to 2.5.3, they should not have to edit their configuraion files (.ini, .hal, tool table, etc). They may choose to edit the files to take advantage of new features, but they should not be forced to edit them just to keep their machine working like it was before. Major revisions are allowed to require changes to configuration files, but the changes should be well documented, preferrably in a step- by-step document. If there are extensive but straightforward changes, a script that can do the grunt work would be much appreciated by the users. Switching from 2.5.6 to 2.6.0 can be expected to cause some pain, but we should try to minimize it. Changing from 2.x.x to 3.0.0 is something we haven't really talked about. Obviously that would imply major structural changes. > > Re length: look at it this way: the remapping code added to the > interpreter was way more massive than the new RTAPI layer in > terms of LOC. AFAICT there are no open bugtracker entries > with bona-fide bugs (modulo Xmas wishes) wrt remapping, and > none which were open more that a few weeks at most. > > That branch is entirely usable, and is used; the windows of > outright brokenness were very short. I see this as something that could be added in a minor revision, since it (hopefully) won't break existing configurations. But to be honest, since it is a major new feature I would think of it more as a version 2.6 thing. > > absolutely. But where do you dry the line between changes that are big > > enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working > > incrementally is all find and good, and if we really refactor various > > pieces of the code to make them more modular or update HAL so we can > > drop NML, Each of these changes are serious enough to be designated a > > revision to version bump. > > the line I see goes like so: > > The messaging-capable HAL layer will have a new API, which > subsumes some of the existing HAL lib functionality. This > should be a published, usable API, meant as a base the using > code in the rest of Linuxcnc (task, GUI's) can be adapted for. > I think it should also aim making HAL/RTAPI and the HAL-based > GUI tools usable standalone, without the rest of Linuxcnc code > draped around it; this isnt only a good sanitary exercise but I > think is is a tempting tool for entirely new, not classic LinuxCNC-type > applications. In fact I see no competing attempt for doing that, but > I see lots of fellows fiddling Arduinos hoping to do something > which that could do, and then some. What exactly do you mean by making HAL/RTAPI usable standalone? It already is - I've done several things that use halrun and a hal file but never load task, motion, or a LinuxCNC GUI. And I know others have done the same. Are you referring to making HAL/RTAPI an independent package that can be installed without the rest of LinuxCNC? -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
