Marc, JBoss team,
Thanks for setting up this branching scheme in CVS. We feel a lot
better about going into production with JBoss knowing that we can patch,
or obtain patches for the JBoss version we ship with. You guys kick ass....
Bill
marc fleury wrote:
> one size fits all if we can...
>
> the reason? version management is a pain, conveys the wrong impressions
> (what? 0.2???) and really is kind of arbitrary.
>
> I am doing this to ***SIMPLIFY*** our support of the problems not
> *complicate*... ok so you have a problem with version 2.2.0 let me get all
> the 2.2.0 so we can rebuild that version.
>
> Otherwise it is going to be painful
>
> you get the idea, that is my opinion,
>
> marc
>
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> |M Stark
> |Sent: Wednesday, April 04, 2001 8:52 PM
> |To: JBoss Development Mailing List (E-mail)
> |Subject: Re: [JBoss-dev] JBoss 2.2.0 FINAL
> |
> |
> |Ok, but cvs tags are pretty much free so why can't a given module have its
> |own versioning, but when a JBoss release is made you tag the module with
> |the JBoss release tag so that one can get all of the JBoss source, core and
> |modules. This isn't really adding coupling betwen the core and
> |modules is it?
> |
> |> >
> |> > I think we need to do the same for the other modules for
> |subsequent releases.
> |>
> |> The approach I favour is to version each module independently.
> |For example,
> |> JBoss currently includes jbosscx-0.2. You can go to the JBossCX
> |module and
> |> check out version 0.2 (because I tagged it) if you need that source code.
> |>
> |> The advantage of doing it this way is that the core is kept
> |decoupled from
> |> the modules. There are some disadvantages, e.g.
> |>
> |> - Updating the module means removing and readding the jar in the
> |core, which
> |> means you need to remember to remove the old jar from your
> |dist directory.
> |> This could perhaps be solved using a more sophisticated
> |install procedure
> |> that copied jbossfoo-x.y.jar to jboss-foo in dist.
> |> - It is not as easy to go the other way, i.e. figure out which version of
> |> JBoss a particular version of the module depends on. This could be
> |> addressed by versioning jboss-client.jar and jboss-util.jar
> |and whatever
> |> else is shared.
> |> - It probably makes it more difficult to issue a single command
> |to grab all
> |> of the source (core and modules) for a specified version. This is the
> |> worst one, I think.
> |>
> |> Toby.
> |>
> |> _______________________________________________
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-development
> |>
> |
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
