Upgrade procedure

[Trav]

I'm curious as to what kind of practices I should follow to allow for
easy upgrades. I figure that I'm going to add features, and your
going to add features, and he's going to add features. How can I
encompass all of them?

The only suggestion I have is that you may want to think about
requiring advanced migrations.

[Steven A Bristol]

On 3/19/08, Trav <mrxt...@yahoo.com> wrote:

I'm curious as to what kind of practices I should follow to allow for
easy upgrades.  I figure that I'm going to add features, and your
going to add features, and he's going to add features.  How can I
encompass all of them?

I don't have a good plan for this yet. Any thoughts? I am thinking that using git might help that. Does anyone have any wisdom here?

The only suggestion I have is that you may want to think about
requiring advanced migrations.

I haven't used advanced migrations. Why is it a good fit?


steve

[Trav]

On Mar 19, 9:32 am, "Steven A Bristol" <stevenbris...@gmail.com>
wrote:

Oops, I meant to say enhanced_migrations. It solves the problem of
creating conflicting migrations. Instead of a sequential numbering
system, advanced migrations uses a timestamp. It also keeps track
individually of which migrations have and have not been run so that
migrations that are added to an environment will still be run even if
they are not in sequence.

>
> steve

[Steven A Bristol]

On 3/19/08, Trav <mrxt...@yahoo.com> wrote:

Oops, I meant to say enhanced_migrations. 

I've been thinking that upgrades would be handled with an upgrade script rather than migrations. That avoids the migration problems entirely.


steve

[Trav]

On Mar 19, 9:32 am, "Steven A Bristol" <stevenbris...@gmail.com>
wrote:

> On 3/19/08, Trav <mrxtra...@yahoo.com> wrote:
>
>
>
> > I'm curious as to what kind of practices I should follow to allow for
> > easy upgrades. I figure that I'm going to add features, and your
> > going to add features, and he's going to add features. How can I
> > encompass all of them?
>
> I don't have a good plan for this yet. Any thoughts? I am thinking that
> using git might help that. Does anyone have any wisdom here?

As a consumer of this product, I would definitely use git. I would
probably keep a branch specifically for following lovdbyless
development. For each release I would update that branch and then
rebase main line development to that branch. Git would make it really
easy.

Git has truly made collaborative development really easy for our team
and I highly recommend it. Having the releases available via a git
repo would be awesome!

[Steven A Bristol]

On 3/19/08, Trav <mrxt...@yahoo.com> wrote:

As a consumer of this product, I would definitely use git.  I would
probably keep a branch specifically for following lovdbyless
development.  For each release I would update that branch and then
rebase main line development to that branch.  Git would make it really
easy.

Git has truly made collaborative development really easy for our team
and I highly recommend it.  Having the releases available via a git
repo would be awesome!

Does anyone else have feelings about git vs svn. Now's your chance to pick a repo... :)


steve

[Chris Cummer]

I've been a long-time Svn user but I'm happy to learn Git.

On Mar 19, 11:59 am, "Steven A Bristol" <stevenbris...@gmail.com>
wrote:

[Cody P.]

I vote for svn, it has more and better available integration with
various toolchains and ides.


On Mar 19, 12:59 pm, "Steven A Bristol" <stevenbris...@gmail.com>
wrote:

[Henry Wagner]

I'm interested in contributing to the code too. I prefer svn (mostly because I've got it setup with my IDE). I'm just starting to play around with git so I'd be up for that too.

--
Henry
http://www.henrywagner.org/

[Greg]

git

putting it on github.com makes it more accessible to rails hackers

On Mar 19, 1:59 pm, "Steven A Bristol" <stevenbris...@gmail.com>
wrote:

[Trav]

On Mar 19, 10:05 pm, "Cody P." <cpi...@gmail.com> wrote:
> I vote for svn, it has more and better available integration with
> various toolchains and ides.

I understand that svn currently has good integration with IDEs and
such, but there are certain things that SVN really sucks at, such as
merging code from multiple branches.

I foresee the use case of LBL to be a good starting point for many
projects. Each project would then add on custom pieces along side the
LBL code, most of which would not be intended to be committed back to
the LBL codebase. However, some custom code would be merged back into
the LBL code base creating a new version of LBL. At some point, each
of those projects would want the latest and greatest LBL. Using git,
this update would be easy to moderately hard. Using subversion, this
update would be hard to impossible.

An alternative may be to use engines. (I have never used engines, but
it may be good for something like this -- anyone?)

[Cody P.]

Engines are a huge pain in the ass. There are lots of yays for git
here, so just go with it!

[steven...@gmail.com]

Thanks everyone for your opinions. Git is it. I have an account set up
at
github and will be pushing lbl tonight. I'll post the deets once I
have
them. I am resolved not to sleep until this is done (among other
things) :).


steve

[steven...@gmail.com]

On Mar 20, 11:51 pm, "stevenbris...@gmail.com"

Did I really type "deets" instead of details? Feel free to loath me
now.


steve

[Henry Wagner]

On Thu, Mar 20, 2008 at 8:52 PM, steven...@gmail.com <steven...@gmail.com> wrote:

Did I really type "deets" instead of details? Feel free to loath me
now.

 

 

LOL!

 

Thanks for all the hard work Steve.

 

I've got the app up and running now, works great.

 

Henry