edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Creating a new git repo for the Edgent project
Date Tue, 07 Nov 2017 17:16:36 GMT
At the end of the day, for me, its whatever the podling thinks it needs to
be successful.  I can only give tips based on what I have seen work.

Just don't forget that having separate samples means that they can out of
date pretty quickly.

John

On Tue, Nov 7, 2017 at 12:10 PM Dale LaBossiere <dml.apache@gmail.com>
wrote:

> Perhaps additional discussion is warranted.
>
> A goal has been to make it easier for folks to get started using Edgent as
> opposed to being builders/developers of Edgent (hence the distribution of
> Edgent jars to maven central).
>
> Being able to easily get the sample sources separate from “Edgent” seems
> right to me.  Yeah, we really don’t need to release a separate sample
> sources bundle to achieve that (and not “releasing” samples makes life
> easier for us).  If the samples are in their own git/github repo then we
> can just point users there and they can easily download/clone.
>
> So, I guess I’m still a proponent of a separate repo but now not doing a
> release / separate source bundle of them.  Make sense?
>
> — Dale
>
>
> > On Nov 7, 2017, at 10:40 AM, John D. Ament <johndament@apache.org>
> wrote:
> >
> > Well, its not an issue to include samples in the main source.  You can
> > release it all together.  You can also release it independently, but
> > typically sample repos aren't released.  Its up to you guys.  I'm of the
> > opinion that if you have a samples/examples repo it shouldn't get
> > released.  You may want to tag it for a specific release so that others
> can
> > reference it.
> >
> > By not releasing a sample repo, you can include incompatible dependencies
> > and not have to worry (just make sure you're being clear about it in the
> > repo's readme).
> >
> > If you want, you can also just exclude the samples from the release
> source.
> >
> > I've seen projects do all three.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message