* Deprecating eCos 2.0
@ 2006-07-12 14:03 Gary Thomas
2006-07-12 15:03 ` Jonathan Larmour
0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2006-07-12 14:03 UTC (permalink / raw)
To: eCos Maintainers
Can we make the automated download tool (ecos-install.tcl) use
a CVS snapshot instead of the old 2.0? It would solve so many
"I'm using 2.0 ..." issues if this was the default.
Note: I don't care if it still downloads the old tools (which
are also labeled 2.0) as for the most part, they don't get
in the way.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecating eCos 2.0
2006-07-12 14:03 Deprecating eCos 2.0 Gary Thomas
@ 2006-07-12 15:03 ` Jonathan Larmour
2006-07-22 17:40 ` Andrew Lunn
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Larmour @ 2006-07-12 15:03 UTC (permalink / raw)
To: Gary Thomas; +Cc: eCos Maintainers
Gary Thomas wrote:
> Can we make the automated download tool (ecos-install.tcl) use
> a CVS snapshot instead of the old 2.0? It would solve so many
> "I'm using 2.0 ..." issues if this was the default.
>
> Note: I don't care if it still downloads the old tools (which
> are also labeled 2.0) as for the most part, they don't get
> in the way.
It's certainly possible. Not a great message in one sense, but it would do
the job for now. Despite not much in the way of QA, it's arguably less
relevant to commend 2.0.
But if we did, it would still want a version number distinct from true CVS,
i.e. instead of "current" for packages. Perhaps something like 2.1a-cvs or
2.1a-interim? We'd also need a doc rebuild to make sense. Similarly what
about the prebuilt configtool and ecosconfig? The only prebuilt versions
that work with cygwin are on ecoscentric's site.
So even a quicky respin isn't quite trivial but it wouldn't take long. Not
something to announce with a fanfare though.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecating eCos 2.0
2006-07-12 15:03 ` Jonathan Larmour
@ 2006-07-22 17:40 ` Andrew Lunn
2006-07-22 22:52 ` Jonathan Larmour
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2006-07-22 17:40 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Gary Thomas, eCos Maintainers
On Wed, Jul 12, 2006 at 04:03:33PM +0100, Jonathan Larmour wrote:
> Gary Thomas wrote:
> >Can we make the automated download tool (ecos-install.tcl) use
> >a CVS snapshot instead of the old 2.0? It would solve so many
> >"I'm using 2.0 ..." issues if this was the default.
> >
> >Note: I don't care if it still downloads the old tools (which
> >are also labeled 2.0) as for the most part, they don't get
> >in the way.
>
> It's certainly possible. Not a great message in one sense, but it would do
> the job for now. Despite not much in the way of QA, it's arguably less
> relevant to commend 2.0.
>
> But if we did, it would still want a version number distinct from true CVS,
> i.e. instead of "current" for packages. Perhaps something like 2.1a-cvs or
> 2.1a-interim? We'd also need a doc rebuild to make sense. Similarly what
> about the prebuilt configtool and ecosconfig? The only prebuilt versions
> that work with cygwin are on ecoscentric's site.
>
> So even a quicky respin isn't quite trivial but it wouldn't take long. Not
> something to announce with a fanfare though.
We always seem to run into these problems a while after a release. We
should think forward for the next release. Do we really want to make a
release with a different version number in the tree? Wouldn't it be
better to just make a snapshot of CVS, with the CVS directories, so
that people can do a cvs up. Also change the documentation to
encourage people to do this as the last part of the installation
process.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Deprecating eCos 2.0
2006-07-22 17:40 ` Andrew Lunn
@ 2006-07-22 22:52 ` Jonathan Larmour
2006-07-24 17:58 ` John Dallaway
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Larmour @ 2006-07-22 22:52 UTC (permalink / raw)
To: Andrew Lunn; +Cc: eCos Maintainers
Andrew Lunn wrote:
>
> We always seem to run into these problems a while after a release.
Well, we've only had one non-Red Hat release ;).
> We
> should think forward for the next release. Do we really want to make a
> release with a different version number in the tree?
I think so yes. Normally it's reasonable to assume that if people
reporting problems have packages with v2_0 in the name, it's a giveaway
that it's old; and if it's "current", then not only is it from cvs, but it
is likely to be recent CVS (even the snapshots via FTP are updated weekly
so people can easily keep up-to-date). If we ship out stuff with "current"
in the package name, there will be a marked increase in people with paths
saying "current" when actually it's out of date. We want to catch when
people are using old sources, and it's not hard to achieve.
> Wouldn't it be
> better to just make a snapshot of CVS, with the CVS directories, so
> that people can do a cvs up. Also change the documentation to
> encourage people to do this as the last part of the installation
> process.
It's a dubious enough suggestion as it is to be making a release that
isn't stabilised (although at least we can fix up any real showstoppers).
Positively encouraging use of sources that can be infrequently but
occasionally seriously broken, seems even less wise.
Jifl
--
------["The best things in life aren't things."]------ Opinions==mine
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecating eCos 2.0
2006-07-22 22:52 ` Jonathan Larmour
@ 2006-07-24 17:58 ` John Dallaway
2006-07-31 8:43 ` Andrew Lunn
0 siblings, 1 reply; 6+ messages in thread
From: John Dallaway @ 2006-07-24 17:58 UTC (permalink / raw)
To: ecos-maintainers
Jonathan Larmour wrote:
> Andrew Lunn wrote:
>
>> Wouldn't it be
>> better to just make a snapshot of CVS, with the CVS directories, so
>> that people can do a cvs up. Also change the documentation to
>> encourage people to do this as the last part of the installation
>> process.
>
> It's a dubious enough suggestion as it is to be making a release that
> isn't stabilised (although at least we can fix up any real
> showstoppers). Positively encouraging use of sources that can be
> infrequently but occasionally seriously broken, seems even less wise.
I agree with Jifl that we need a way to readily distinguish official
releases from CVS checkouts. Official releases cater for a different
class of user who cares more about stability than about the very latest
features. Of course, we need to do what we can to ensure that the next
official release lives up to such expectations. I would support
retaining the "v2_x" style of version directories for future releases.
Users always have the option of checking out a specific version of eCos
from CVS using a release tag if they prefer a stable repository that can
be updated in the future.
John Dallaway
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecating eCos 2.0
2006-07-24 17:58 ` John Dallaway
@ 2006-07-31 8:43 ` Andrew Lunn
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Lunn @ 2006-07-31 8:43 UTC (permalink / raw)
To: John Dallaway; +Cc: ecos-maintainers
My access to email has been a bit spotty, so sorry about taking so
long to reply. Im back home now, but life is still a bit chaotic.
It seems like we are staying with a version number. O.K.
Then i suggest we modify the Download and Install page. Add some text
about what the release snapshot is and is not and what the anonycvs is
and is not. Also, make sure the date for the release snapshot is
clearly stated.
This would make it clearer when somebody is doing there first download
as to what they are getting and should hopefully reduce some of our
problems with historical code.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-31 8:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-07-12 14:03 Deprecating eCos 2.0 Gary Thomas
2006-07-12 15:03 ` Jonathan Larmour
2006-07-22 17:40 ` Andrew Lunn
2006-07-22 22:52 ` Jonathan Larmour
2006-07-24 17:58 ` John Dallaway
2006-07-31 8:43 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).