rails-devel

[Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

A new bug-fix release 1.5.1 for Rails is available.

Downloads are available at http://rails.sourceforge.net/ or by the
direct link https://sourceforge.net/projects/rails/files/Rails/1.5.1/

It contains:

- Fix to allow laying THB home token if track exists (1856).
- Fix bug that disallows selling a share after buying one in some cases.
- Fixed positioning bug of base tokens on corner-facing cities.
- Fix of revenue calculation: Changed Montgomery and Tallahassee to major 
scoring locations (18GA).

Stefan

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

Stefan,

It seems you forgot to change the version number in Game.java.  When I pull,
it's still 1.5.
In any case, with my next commit I will change it to 1.5.1+.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 11:42 AM
> To: rai...@li...
> Cc: Development list for Rails: an 18xx game; rails-
> us...@li...
> Subject: [Rails-devel] Rails 1.5.1 available
> 
> A new bug-fix release 1.5.1 for Rails is available.
> 
> Downloads are available at http://rails.sourceforge.net/ or by the direct
link
> https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> 
> It contains:
> 
> - Fix to allow laying THB home token if track exists (1856).
> - Fix bug that disallows selling a share after buying one in some cases.
> - Fixed positioning bug of base tokens on corner-facing cities.
> - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
> scoring locations (18GA).
> 
> Stefan
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

Erik:
I have not forgotten to  change the version number, but the master branch is 
the the developing branch for Rails 1.6. Thus you should change the version 
number for master to Rails 1.5.9+ or 1.6- 

I created a local branch for bug-fixes of Rails 1.5 for which I picked those 
commits that were bug-fixes (using git cherry-pick). Inside this local branch 
the version number is correctly set to 1.5.1.

I would prefer not to upload that local branch to the git repo to avoid that 
someone starts coding bug-fixes against this (stable) branch instead of the 
master branch (for the Rails 1.x development). The major disadvantage of that 
is that the remote repo has no tag for 1.5.1.

The other remote branch is for development towards Rails 2.0: 
I am getting closer to a first compiling version, however it proved that 
refactoring and a cautious redesigning of the state/model classes to remove 
the two different types of state/move mechanisms proved to be some more work 
than expected. However it will make everything around Porfolio and Ownership a 
little easier: Currently I delete more lines than I add.

Stefan







On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> Stefan,
> 
> It seems you forgot to change the version number in Game.java.  When I
> pull, it's still 1.5.
> In any case, with my next commit I will change it to 1.5.1+.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, October 10, 2011 11:42 AM
> > To: rai...@li...
> > Cc: Development list for Rails: an 18xx game; rails-
> > us...@li...
> > Subject: [Rails-devel] Rails 1.5.1 available
> > 
> > A new bug-fix release 1.5.1 for Rails is available.
> > 
> > Downloads are available at http://rails.sourceforge.net/ or by the direct
> 
> link
> 
> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> > 
> > It contains:
> > 
> > - Fix to allow laying THB home token if track exists (1856).
> > - Fix bug that disallows selling a share after buying one in some cases.
> > - Fixed positioning bug of base tokens on corner-facing cities.
> > - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
> > scoring locations (18GA).
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> - --
> 
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of
> 
> it.
> 
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

If it's a published release, there needs to be a public tag
referencing it in the git repo.

If you'd like to discuss changes in the release methodology, you
should do it *before* you do a release with a new methodology.

---Brett.



On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> Erik:
> I have not forgotten to  change the version number, but the master branch is
> the the developing branch for Rails 1.6. Thus you should change the version
> number for master to Rails 1.5.9+ or 1.6-
>
> I created a local branch for bug-fixes of Rails 1.5 for which I picked those
> commits that were bug-fixes (using git cherry-pick). Inside this local branch
> the version number is correctly set to 1.5.1.
>
> I would prefer not to upload that local branch to the git repo to avoid that
> someone starts coding bug-fixes against this (stable) branch instead of the
> master branch (for the Rails 1.x development). The major disadvantage of that
> is that the remote repo has no tag for 1.5.1.
>
> The other remote branch is for development towards Rails 2.0:
> I am getting closer to a first compiling version, however it proved that
> refactoring and a cautious redesigning of the state/model classes to remove
> the two different types of state/move mechanisms proved to be some more work
> than expected. However it will make everything around Porfolio and Ownership a
> little easier: Currently I delete more lines than I add.
>
> Stefan
>
>
>
>
>
>
>
> On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> Stefan,
>>
>> It seems you forgot to change the version number in Game.java.  When I
>> pull, it's still 1.5.
>> In any case, with my next commit I will change it to 1.5.1+.
>>
>> Erik.
>>
>> > -----Original Message-----
>> > From: Stefan Frey [mailto:ste...@we...]
>> > Sent: Monday, October 10, 2011 11:42 AM
>> > To: rai...@li...
>> > Cc: Development list for Rails: an 18xx game; rails-
>> > us...@li...
>> > Subject: [Rails-devel] Rails 1.5.1 available
>> >
>> > A new bug-fix release 1.5.1 for Rails is available.
>> >
>> > Downloads are available at http://rails.sourceforge.net/ or by the direct
>>
>> link
>>
>> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >
>> > It contains:
>> >
>> > - Fix to allow laying THB home token if track exists (1856).
>> > - Fix bug that disallows selling a share after buying one in some cases.
>> > - Fixed positioning bug of base tokens on corner-facing cities.
>> > - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
>> > scoring locations (18GA).
>> >
>> > Stefan
>>
>> ---------------------------------------------------------------------------
>> - --
>>
>> > All the data continuously generated in your IT infrastructure contains a
>> > definitive record of customers, application performance, security
>> > threats, fraudulent activity and more. Splunk takes this data and makes
>> > sense of
>>
>> it.
>>
>> > Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

Brett:
welcome back to the discussion: I hope you finished your cross-country move 
successfully. 

I do not fully understand what you critique refers to?

* Actually I did propose more frequent bug-fix releases already before the 
release of 1.5.

* I mailed out yesterday that I would plan a release that only includes the 
bug-fixes from the current master (Rails 1.x branch). 

* My e-mail to Erik was asking if there is any interest in uploading a Rails 
1.5.x branch to the repo. The advantage is that this also uploads the 
1.5.1.tag. Disadvantage is that it would add a branch to the repo which should 
not be used for developing. And it seems that I would have to add new branches 
with every 1.y release to allow for bug-fixes to that release.

A possible solution could be to re-order the commits of the master branch such 
that the bug-fixes are at bottom (earlier) than the ones that are adding new 
stuff. However I do not know how to this and I thought (due to the never 
change public history) it is not wise to do so. But if you have a better 
solution for it.
 
But I am open for any (better or different) solution. And to state that again: 
The move to git was a great improvement which easily allows doing such things.

Stefan



On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
> If it's a published release, there needs to be a public tag
> referencing it in the git repo.
> 
> If you'd like to discuss changes in the release methodology, you
> should do it *before* you do a release with a new methodology.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> > Erik:
> > I have not forgotten to  change the version number, but the master branch
> > is the the developing branch for Rails 1.6. Thus you should change the
> > version number for master to Rails 1.5.9+ or 1.6-
> > 
> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
> > those commits that were bug-fixes (using git cherry-pick). Inside this
> > local branch the version number is correctly set to 1.5.1.
> > 
> > I would prefer not to upload that local branch to the git repo to avoid
> > that someone starts coding bug-fixes against this (stable) branch
> > instead of the master branch (for the Rails 1.x development). The major
> > disadvantage of that is that the remote repo has no tag for 1.5.1.
> > 
> > The other remote branch is for development towards Rails 2.0:
> > I am getting closer to a first compiling version, however it proved that
> > refactoring and a cautious redesigning of the state/model classes to
> > remove the two different types of state/move mechanisms proved to be
> > some more work than expected. However it will make everything around
> > Porfolio and Ownership a little easier: Currently I delete more lines
> > than I add.
> > 
> > Stefan
> > 
> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> >> Stefan,
> >> 
> >> It seems you forgot to change the version number in Game.java.  When I
> >> pull, it's still 1.5.
> >> In any case, with my next commit I will change it to 1.5.1+.
> >> 
> >> Erik.
> >> 
> >> > -----Original Message-----
> >> > From: Stefan Frey [mailto:ste...@we...]
> >> > Sent: Monday, October 10, 2011 11:42 AM
> >> > To: rai...@li...
> >> > Cc: Development list for Rails: an 18xx game; rails-
> >> > us...@li...
> >> > Subject: [Rails-devel] Rails 1.5.1 available
> >> > 
> >> > A new bug-fix release 1.5.1 for Rails is available.
> >> > 
> >> > Downloads are available at http://rails.sourceforge.net/ or by the
> >> > direct
> >> 
> >> link
> >> 
> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> >> > 
> >> > It contains:
> >> > 
> >> > - Fix to allow laying THB home token if track exists (1856).
> >> > - Fix bug that disallows selling a share after buying one in some
> >> > cases. - Fixed positioning bug of base tokens on corner-facing
> >> > cities. - Fix of revenue calculation: Changed Montgomery and
> >> > Tallahassee to major scoring locations (18GA).
> >> > 
> >> > Stefan
> >> 
> >> ------------------------------------------------------------------------
> >> --- - --
> >> 
> >> > All the data continuously generated in your IT infrastructure contains
> >> > a definitive record of customers, application performance, security
> >> > threats, fraudulent activity and more. Splunk takes this data and
> >> > makes sense of
> >> 
> >> it.
> >> 
> >> > Business sense. IT sense. Common sense.
> >> > http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

Stefan,

Thanks, it's clear now.
But I would prefer to leave the next version number undecided, be it 1.5.2
or 1.6, until we have a clue what changes it will have. 
So I prefer to stick with 1.5.1+ for the master branch. (I'm only pushing
and pulling master.)

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 6:18 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails 1.5.1 available
> 
> Erik:
> I have not forgotten to  change the version number, but the master branch
is
> the the developing branch for Rails 1.6. Thus you should change the
version
> number for master to Rails 1.5.9+ or 1.6-
> 
> I created a local branch for bug-fixes of Rails 1.5 for which I picked
those
> commits that were bug-fixes (using git cherry-pick). Inside this local
branch
> the version number is correctly set to 1.5.1.
> 
> I would prefer not to upload that local branch to the git repo to avoid
that
> someone starts coding bug-fixes against this (stable) branch instead of
the
> master branch (for the Rails 1.x development). The major disadvantage of
> that is that the remote repo has no tag for 1.5.1.
> 
> The other remote branch is for development towards Rails 2.0:
> I am getting closer to a first compiling version, however it proved that
> refactoring and a cautious redesigning of the state/model classes to
remove
> the two different types of state/move mechanisms proved to be some more
> work than expected. However it will make everything around Porfolio and
> Ownership a little easier: Currently I delete more lines than I add.
> 
> Stefan
> 
> 
> 
> 
> 
> 
> 
> On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> > Stefan,
> >
> > It seems you forgot to change the version number in Game.java.  When I
> > pull, it's still 1.5.
> > In any case, with my next commit I will change it to 1.5.1+.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Monday, October 10, 2011 11:42 AM
> > > To: rai...@li...
> > > Cc: Development list for Rails: an 18xx game; rails-
> > > us...@li...
> > > Subject: [Rails-devel] Rails 1.5.1 available
> > >
> > > A new bug-fix release 1.5.1 for Rails is available.
> > >
> > > Downloads are available at http://rails.sourceforge.net/ or by the
> > > direct
> >
> > link
> >
> > > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> > >
> > > It contains:
> > >
> > > - Fix to allow laying THB home token if track exists (1856).
> > > - Fix bug that disallows selling a share after buying one in some
cases.
> > > - Fixed positioning bug of base tokens on corner-facing cities.
> > > - Fix of revenue calculation: Changed Montgomery and Tallahassee to
> > > major scoring locations (18GA).
> > >
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > All the data continuously generated in your IT infrastructure
> > > contains a definitive record of customers, application performance,
> > > security threats, fraudulent activity and more. Splunk takes this
> > > data and makes sense of
> >
> > it.
> >
> > > Business sense. IT sense. Common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

Comments inline...

On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> welcome back to the discussion: I hope you finished your cross-country move
> successfully.
>

Yup, it was successful (and fun). Now comes the "joy" of unpacking and
getting settled. I've got internet and basic amenities, but it'll
probably be a month or two before I'm completely done.

I'm at least unpacked enough to be able to do everything online that I need to.

> I do not fully understand what you critique refers to?
>

My critique refers to the fact that I can't clone the git repo and
identify what point in the history 1.5.1 was built from.

The 1.5.1 release should be marked as an annotated tag or, in this
case, a published branch, so that anybody can build any release they
might need. This also helps in tracking down regressions and doing git
bisects.

Historically, we've never done releases that target specific bugs or
specific changes while leaving the "in development" work unpackaged.
It's always been shipping out everything when ever we felt that it was
stable enough for wider distribution.

I'm not opposed to changing that process. I /do/ object to making
changes without discussing them adequately, however. I also very much
object to re-ordering history so as to make a tag unpublishable.

> * Actually I did propose more frequent bug-fix releases already before the
> release of 1.5.
>

I saw that. I have no problem with /that/ a release was done. My
objection is to /how/ it was done.

> * I mailed out yesterday that I would plan a release that only includes the
> bug-fixes from the current master (Rails 1.x branch).
>

Yes, but what you didn't say was that because of your plan A) you
would not be tagging master in the way it's been done in the past, and
B) that you would not be publishing a branch or tag that represents
the release.

Those are key parts of the release process that were just silently skipped over.

> * My e-mail to Erik was asking if there is any interest in uploading a Rails
> 1.5.x branch to the repo. The advantage is that this also uploads the
> 1.5.1.tag. Disadvantage is that it would add a branch to the repo which should
> not be used for developing. And it seems that I would have to add new branches
> with every 1.y release to allow for bug-fixes to that release.
>

This needs to be a discussion for all of rails-devel to comment on.
While you and Erik are the primary contributors, this sort of change
affects everyone and so everyone should have the opportunity to
comment on something that will potentially affect them.

We all should be defaulting to open communication and then, if
necessary, more detailed discussion can happen off-list.

> A possible solution could be to re-order the commits of the master branch such
> that the bug-fixes are at bottom (earlier) than the ones that are adding new
> stuff. However I do not know how to this and I thought (due to the never
> change public history) it is not wise to do so. But if you have a better
> solution for it.
>

Git rebase exists to do this, but once the commits are pushed to the
public repo, they should not be re-ordered because it will cause
problems with everyone else's local repo that has the old history.

> But I am open for any (better or different) solution. And to state that again:
> The move to git was a great improvement which easily allows doing such things.
>
> Stefan
>

I agree. Git allows us to do things in ways that CVS and Subversion
were incapable of supporting. I understand that.

To be clear, there's no need to change what's been published. Let's
just figure out where we go from here.

Personally, I'm okay with pushing a tag that's "close" to what we
published in 1.5.1. In other words, find the commit that includes all
of the fixes that 1.5.1 contained, and tag it. While this will include
other work, it's probably "close enough" for maintaining relative
consistency with the existing tags. (I'm also open to discussing other
options.)

---Brett.


>
>
> On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
>> If it's a published release, there needs to be a public tag
>> referencing it in the git repo.
>>
>> If you'd like to discuss changes in the release methodology, you
>> should do it *before* you do a release with a new methodology.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
>> > Erik:
>> > I have not forgotten to  change the version number, but the master branch
>> > is the the developing branch for Rails 1.6. Thus you should change the
>> > version number for master to Rails 1.5.9+ or 1.6-
>> >
>> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
>> > those commits that were bug-fixes (using git cherry-pick). Inside this
>> > local branch the version number is correctly set to 1.5.1.
>> >
>> > I would prefer not to upload that local branch to the git repo to avoid
>> > that someone starts coding bug-fixes against this (stable) branch
>> > instead of the master branch (for the Rails 1.x development). The major
>> > disadvantage of that is that the remote repo has no tag for 1.5.1.
>> >
>> > The other remote branch is for development towards Rails 2.0:
>> > I am getting closer to a first compiling version, however it proved that
>> > refactoring and a cautious redesigning of the state/model classes to
>> > remove the two different types of state/move mechanisms proved to be
>> > some more work than expected. However it will make everything around
>> > Porfolio and Ownership a little easier: Currently I delete more lines
>> > than I add.
>> >
>> > Stefan
>> >
>> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> >> Stefan,
>> >>
>> >> It seems you forgot to change the version number in Game.java.  When I
>> >> pull, it's still 1.5.
>> >> In any case, with my next commit I will change it to 1.5.1+.
>> >>
>> >> Erik.
>> >>
>> >> > -----Original Message-----
>> >> > From: Stefan Frey [mailto:ste...@we...]
>> >> > Sent: Monday, October 10, 2011 11:42 AM
>> >> > To: rai...@li...
>> >> > Cc: Development list for Rails: an 18xx game; rails-
>> >> > us...@li...
>> >> > Subject: [Rails-devel] Rails 1.5.1 available
>> >> >
>> >> > A new bug-fix release 1.5.1 for Rails is available.
>> >> >
>> >> > Downloads are available at http://rails.sourceforge.net/ or by the
>> >> > direct
>> >>
>> >> link
>> >>
>> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >> >
>> >> > It contains:
>> >> >
>> >> > - Fix to allow laying THB home token if track exists (1856).
>> >> > - Fix bug that disallows selling a share after buying one in some
>> >> > cases. - Fixed positioning bug of base tokens on corner-facing
>> >> > cities. - Fix of revenue calculation: Changed Montgomery and
>> >> > Tallahassee to major scoring locations (18GA).
>> >> >
>> >> > Stefan
>> >>

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also
> > uploads the 1.5.1.tag. Disadvantage is that it would add a branch to
> > the repo which should not be used for developing. And it seems that I
> > would have to add new branches with every 1.y release to allow for bug-
> fixes to that release.
> >
> 
> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change affects
> everyone and so everyone should have the opportunity to comment on
> something that will potentially affect them.

I have no opinion on whether or not to put branches in the repo, as I ignore them all (so far).  
However, I would like to see a correct (if temporary) version number in the master Game.xml, so that the approximate version of saved files can be identified.
In my opinion that should be 1.5.1+, literally: 1.5.1 and more.
(A build number would be even better, once we have managed nightly or weekly builds. Would it be possible to have the code retrieve the latest commit hash?)

Erik.

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

To clarify  one detail first: 
> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
> > which should not be used for developing. And it seems that I would have
> > to add new branches with every 1.y release to allow for bug-fixes to
> > that release.

> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change
> affects everyone and so everyone should have the opportunity to
> comment on something that will potentially affect them.

This e-mail mentioned above was sent to the devel list, I only used the name 
Erik as the addressee of the mail in the first line.

However I think we are not far away from each other.

Seems that there are two issues where we differ:

A) Publishing the Rails 1.5.x branch
I know that for a open source project everything should be open to the public. 
But as the commits going into Rails 1.5.1 is a subset of the public commits 
there is nothing material missing inside the repo.
But as my initial e-mail expressed I am really undecided on this issue, so I 
will follow your advice and publish my Rails 1.5.x branch to the repo.
By definition I have nothing to hide here ;-)
But everyone keep in mind that you should not use that branch instead code 
against master.

B) Publishing only bug-fixes
Here I think we differ a little more: I did the work to pick only those 
commits that are bug-fixes. Simply tagging the head of master in fact is 
easier. 
I did this to improve the likelihood that the bug-fix release fixes more bugs 
than opening new ones. I appreciate those projects that have a clear 
separation of a stable branch with bug-fixes and a development branch with new 
features. As git makes this easy to accomplish I chose that route.

But if you seriously object to this we can go back to the old style for  
release management.

Stefan


On Monday, October 10, 2011 07:32:06 pm brett lentz wrote:
> Comments inline...
> 
> On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
> > Brett:
> > welcome back to the discussion: I hope you finished your cross-country
> > move successfully.
> 
> Yup, it was successful (and fun). Now comes the "joy" of unpacking and
> getting settled. I've got internet and basic amenities, but it'll
> probably be a month or two before I'm completely done.
> 
> I'm at least unpacked enough to be able to do everything online that I need
> to.
> 
> > I do not fully understand what you critique refers to?
> 
> My critique refers to the fact that I can't clone the git repo and
> identify what point in the history 1.5.1 was built from.
> 
> The 1.5.1 release should be marked as an annotated tag or, in this
> case, a published branch, so that anybody can build any release they
> might need. This also helps in tracking down regressions and doing git
> bisects.
> 
> Historically, we've never done releases that target specific bugs or
> specific changes while leaving the "in development" work unpackaged.
> It's always been shipping out everything when ever we felt that it was
> stable enough for wider distribution.
> 
> I'm not opposed to changing that process. I /do/ object to making
> changes without discussing them adequately, however. I also very much
> object to re-ordering history so as to make a tag unpublishable.
> 
> > * Actually I did propose more frequent bug-fix releases already before
> > the release of 1.5.
> 
> I saw that. I have no problem with /that/ a release was done. My
> objection is to /how/ it was done.
> 
> > * I mailed out yesterday that I would plan a release that only includes
> > the bug-fixes from the current master (Rails 1.x branch).
> 
> Yes, but what you didn't say was that because of your plan A) you
> would not be tagging master in the way it's been done in the past, and
> B) that you would not be publishing a branch or tag that represents
> the release.
> 
> Those are key parts of the release process that were just silently skipped
> over.
> 
> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
> > which should not be used for developing. And it seems that I would have
> > to add new branches with every 1.y release to allow for bug-fixes to
> > that release.
> 
> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change
> affects everyone and so everyone should have the opportunity to
> comment on something that will potentially affect them.
> 
> We all should be defaulting to open communication and then, if
> necessary, more detailed discussion can happen off-list.
> 
> > A possible solution could be to re-order the commits of the master branch
> > such that the bug-fixes are at bottom (earlier) than the ones that are
> > adding new stuff. However I do not know how to this and I thought (due
> > to the never change public history) it is not wise to do so. But if you
> > have a better solution for it.
> 
> Git rebase exists to do this, but once the commits are pushed to the
> public repo, they should not be re-ordered because it will cause
> problems with everyone else's local repo that has the old history.
> 
> > But I am open for any (better or different) solution. And to state that
> > again: The move to git was a great improvement which easily allows doing
> > such things.
> > 
> > Stefan
> 
> I agree. Git allows us to do things in ways that CVS and Subversion
> were incapable of supporting. I understand that.
> 
> To be clear, there's no need to change what's been published. Let's
> just figure out where we go from here.
> 
> Personally, I'm okay with pushing a tag that's "close" to what we
> published in 1.5.1. In other words, find the commit that includes all
> of the fixes that 1.5.1 contained, and tag it. While this will include
> other work, it's probably "close enough" for maintaining relative
> consistency with the existing tags. (I'm also open to discussing other
> options.)
> 
> ---Brett.
> 
> > On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
> >> If it's a published release, there needs to be a public tag
> >> referencing it in the git repo.
> >> 
> >> If you'd like to discuss changes in the release methodology, you
> >> should do it *before* you do a release with a new methodology.
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> >> > Erik:
> >> > I have not forgotten to  change the version number, but the master
> >> > branch is the the developing branch for Rails 1.6. Thus you should
> >> > change the version number for master to Rails 1.5.9+ or 1.6-
> >> > 
> >> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
> >> > those commits that were bug-fixes (using git cherry-pick). Inside this
> >> > local branch the version number is correctly set to 1.5.1.
> >> > 
> >> > I would prefer not to upload that local branch to the git repo to
> >> > avoid that someone starts coding bug-fixes against this (stable)
> >> > branch instead of the master branch (for the Rails 1.x development).
> >> > The major disadvantage of that is that the remote repo has no tag for
> >> > 1.5.1.
> >> > 
> >> > The other remote branch is for development towards Rails 2.0:
> >> > I am getting closer to a first compiling version, however it proved
> >> > that refactoring and a cautious redesigning of the state/model
> >> > classes to remove the two different types of state/move mechanisms
> >> > proved to be some more work than expected. However it will make
> >> > everything around Porfolio and Ownership a little easier: Currently I
> >> > delete more lines than I add.
> >> > 
> >> > Stefan
> >> > 
> >> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> >> >> Stefan,
> >> >> 
> >> >> It seems you forgot to change the version number in Game.java.  When
> >> >> I pull, it's still 1.5.
> >> >> In any case, with my next commit I will change it to 1.5.1+.
> >> >> 
> >> >> Erik.
> >> >> 
> >> >> > -----Original Message-----
> >> >> > From: Stefan Frey [mailto:ste...@we...]
> >> >> > Sent: Monday, October 10, 2011 11:42 AM
> >> >> > To: rai...@li...
> >> >> > Cc: Development list for Rails: an 18xx game; rails-
> >> >> > us...@li...
> >> >> > Subject: [Rails-devel] Rails 1.5.1 available
> >> >> > 
> >> >> > A new bug-fix release 1.5.1 for Rails is available.
> >> >> > 
> >> >> > Downloads are available at http://rails.sourceforge.net/ or by the
> >> >> > direct
> >> >> 
> >> >> link
> >> >> 
> >> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> >> >> > 
> >> >> > It contains:
> >> >> > 
> >> >> > - Fix to allow laying THB home token if track exists (1856).
> >> >> > - Fix bug that disallows selling a share after buying one in some
> >> >> > cases. - Fixed positioning bug of base tokens on corner-facing
> >> >> > cities. - Fix of revenue calculation: Changed Montgomery and
> >> >> > Tallahassee to major scoring locations (18GA).
> >> >> > 
> >> >> > Stefan
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

Erik:
you are right 1.5.1+ is correct, my train of thought got sidetracked.

I was thinking about that too, as changing the version number is the only 
remaining manual task to publish a new release.

However there will always the need to update the wiki and html pages, so it 
still requires manually intervention.

I am considering adding webstart support (in addition to the file releases - 
not as an replacement), but I want like to know the opinions of the others 
about that?

Stefan


> 
> I have no opinion on whether or not to put branches in the repo, as I
> ignore them all (so far). However, I would like to see a correct (if
> temporary) version number in the master Game.xml, so that the approximate
> version of saved files can be identified. In my opinion that should be
> 1.5.1+, literally: 1.5.1 and more.
> (A build number would be even better, once we have managed nightly or
> weekly builds. Would it be possible to have the code retrieve the latest
> commit hash?)
> 
> Erik.
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

On Mon, Oct 10, 2011 at 1:55 PM, Stefan Frey <ste...@we...> wrote:
> To clarify  one detail first:
>> > * My e-mail to Erik was asking if there is any interest in uploading a
>> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
>> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
>> > which should not be used for developing. And it seems that I would have
>> > to add new branches with every 1.y release to allow for bug-fixes to
>> > that release.
>
>> This needs to be a discussion for all of rails-devel to comment on.
>> While you and Erik are the primary contributors, this sort of change
>> affects everyone and so everyone should have the opportunity to
>> comment on something that will potentially affect them.
>
> This e-mail mentioned above was sent to the devel list, I only used the name
> Erik as the addressee of the mail in the first line.
>
> However I think we are not far away from each other.
>
> Seems that there are two issues where we differ:
>
> A) Publishing the Rails 1.5.x branch
> I know that for a open source project everything should be open to the public.
> But as the commits going into Rails 1.5.1 is a subset of the public commits
> there is nothing material missing inside the repo.
> But as my initial e-mail expressed I am really undecided on this issue, so I
> will follow your advice and publish my Rails 1.5.x branch to the repo.
> By definition I have nothing to hide here ;-)
> But everyone keep in mind that you should not use that branch instead code
> against master.
>
> B) Publishing only bug-fixes
> Here I think we differ a little more: I did the work to pick only those
> commits that are bug-fixes. Simply tagging the head of master in fact is
> easier.
> I did this to improve the likelihood that the bug-fix release fixes more bugs
> than opening new ones. I appreciate those projects that have a clear
> separation of a stable branch with bug-fixes and a development branch with new
> features. As git makes this easy to accomplish I chose that route.
>
> But if you seriously object to this we can go back to the old style for
> release management.
>

It's far more important to me that each release is accessible from the
repo. How it achieves that is totally negotiable.

Personally, because you and Erik are far more active in the project
than I am, I'm willing to give your preferences a bit more weight than
mine. ;-)

IMO, it's easier to leave master as the lineage of stable changes and
do any new development in (usually local) branches that can be merged
into the stable trunk when they're ready.

In git, branches and tags are both very very cheap (and fast), unlike
SVN. So, if you want to have all development happen in master, then
branch off for stable releases, we can do that too.

> Stefan
>

---Brett


>
> On Monday, October 10, 2011 07:32:06 pm brett lentz wrote:
>> Comments inline...
>>
>> On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
>> > Brett:
>> > welcome back to the discussion: I hope you finished your cross-country
>> > move successfully.
>>
>> Yup, it was successful (and fun). Now comes the "joy" of unpacking and
>> getting settled. I've got internet and basic amenities, but it'll
>> probably be a month or two before I'm completely done.
>>
>> I'm at least unpacked enough to be able to do everything online that I need
>> to.
>>
>> > I do not fully understand what you critique refers to?
>>
>> My critique refers to the fact that I can't clone the git repo and
>> identify what point in the history 1.5.1 was built from.
>>
>> The 1.5.1 release should be marked as an annotated tag or, in this
>> case, a published branch, so that anybody can build any release they
>> might need. This also helps in tracking down regressions and doing git
>> bisects.
>>
>> Historically, we've never done releases that target specific bugs or
>> specific changes while leaving the "in development" work unpackaged.
>> It's always been shipping out everything when ever we felt that it was
>> stable enough for wider distribution.
>>
>> I'm not opposed to changing that process. I /do/ object to making
>> changes without discussing them adequately, however. I also very much
>> object to re-ordering history so as to make a tag unpublishable.
>>
>> > * Actually I did propose more frequent bug-fix releases already before
>> > the release of 1.5.
>>
>> I saw that. I have no problem with /that/ a release was done. My
>> objection is to /how/ it was done.
>>
>> > * I mailed out yesterday that I would plan a release that only includes
>> > the bug-fixes from the current master (Rails 1.x branch).
>>
>> Yes, but what you didn't say was that because of your plan A) you
>> would not be tagging master in the way it's been done in the past, and
>> B) that you would not be publishing a branch or tag that represents
>> the release.
>>
>> Those are key parts of the release process that were just silently skipped
>> over.
>>
>> > * My e-mail to Erik was asking if there is any interest in uploading a
>> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
>> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
>> > which should not be used for developing. And it seems that I would have
>> > to add new branches with every 1.y release to allow for bug-fixes to
>> > that release.
>>
>> This needs to be a discussion for all of rails-devel to comment on.
>> While you and Erik are the primary contributors, this sort of change
>> affects everyone and so everyone should have the opportunity to
>> comment on something that will potentially affect them.
>>
>> We all should be defaulting to open communication and then, if
>> necessary, more detailed discussion can happen off-list.
>>
>> > A possible solution could be to re-order the commits of the master branch
>> > such that the bug-fixes are at bottom (earlier) than the ones that are
>> > adding new stuff. However I do not know how to this and I thought (due
>> > to the never change public history) it is not wise to do so. But if you
>> > have a better solution for it.
>>
>> Git rebase exists to do this, but once the commits are pushed to the
>> public repo, they should not be re-ordered because it will cause
>> problems with everyone else's local repo that has the old history.
>>
>> > But I am open for any (better or different) solution. And to state that
>> > again: The move to git was a great improvement which easily allows doing
>> > such things.
>> >
>> > Stefan
>>
>> I agree. Git allows us to do things in ways that CVS and Subversion
>> were incapable of supporting. I understand that.
>>
>> To be clear, there's no need to change what's been published. Let's
>> just figure out where we go from here.
>>
>> Personally, I'm okay with pushing a tag that's "close" to what we
>> published in 1.5.1. In other words, find the commit that includes all
>> of the fixes that 1.5.1 contained, and tag it. While this will include
>> other work, it's probably "close enough" for maintaining relative
>> consistency with the existing tags. (I'm also open to discussing other
>> options.)
>>
>> ---Brett.
>>
>> > On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
>> >> If it's a published release, there needs to be a public tag
>> >> referencing it in the git repo.
>> >>
>> >> If you'd like to discuss changes in the release methodology, you
>> >> should do it *before* you do a release with a new methodology.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
>> >> > Erik:
>> >> > I have not forgotten to  change the version number, but the master
>> >> > branch is the the developing branch for Rails 1.6. Thus you should
>> >> > change the version number for master to Rails 1.5.9+ or 1.6-
>> >> >
>> >> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
>> >> > those commits that were bug-fixes (using git cherry-pick). Inside this
>> >> > local branch the version number is correctly set to 1.5.1.
>> >> >
>> >> > I would prefer not to upload that local branch to the git repo to
>> >> > avoid that someone starts coding bug-fixes against this (stable)
>> >> > branch instead of the master branch (for the Rails 1.x development).
>> >> > The major disadvantage of that is that the remote repo has no tag for
>> >> > 1.5.1.
>> >> >
>> >> > The other remote branch is for development towards Rails 2.0:
>> >> > I am getting closer to a first compiling version, however it proved
>> >> > that refactoring and a cautious redesigning of the state/model
>> >> > classes to remove the two different types of state/move mechanisms
>> >> > proved to be some more work than expected. However it will make
>> >> > everything around Porfolio and Ownership a little easier: Currently I
>> >> > delete more lines than I add.
>> >> >
>> >> > Stefan
>> >> >
>> >> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> >> >> Stefan,
>> >> >>
>> >> >> It seems you forgot to change the version number in Game.java.  When
>> >> >> I pull, it's still 1.5.
>> >> >> In any case, with my next commit I will change it to 1.5.1+.
>> >> >>
>> >> >> Erik.
>> >> >>
>> >> >> > -----Original Message-----
>> >> >> > From: Stefan Frey [mailto:ste...@we...]
>> >> >> > Sent: Monday, October 10, 2011 11:42 AM
>> >> >> > To: rai...@li...
>> >> >> > Cc: Development list for Rails: an 18xx game; rails-
>> >> >> > us...@li...
>> >> >> > Subject: [Rails-devel] Rails 1.5.1 available
>> >> >> >
>> >> >> > A new bug-fix release 1.5.1 for Rails is available.
>> >> >> >
>> >> >> > Downloads are available at http://rails.sourceforge.net/ or by the
>> >> >> > direct
>> >> >>
>> >> >> link
>> >> >>
>> >> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >> >> >
>> >> >> > It contains:
>> >> >> >
>> >> >> > - Fix to allow laying THB home token if track exists (1856).
>> >> >> > - Fix bug that disallows selling a share after buying one in some
>> >> >> > cases. - Fixed positioning bug of base tokens on corner-facing
>> >> >> > cities. - Fix of revenue calculation: Changed Montgomery and
>> >> >> > Tallahassee to major scoring locations (18GA).
>> >> >> >
>> >> >> > Stefan
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

> 
> It's far more important to me that each release is accessible from the
> repo. How it achieves that is totally negotiable.
> 
> Personally, because you and Erik are far more active in the project
> than I am, I'm willing to give your preferences a bit more weight than
> mine. ;-)
> 
> IMO, it's easier to leave master as the lineage of stable changes and
> do any new development in (usually local) branches that can be merged
> into the stable trunk when they're ready.
> 
> In git, branches and tags are both very very cheap (and fast), unlike
> SVN. So, if you want to have all development happen in master, then
> branch off for stable releases, we can do that too.

I understood that for Erik the latter is the preferred choice. And I do not 
mind to manually pick the fixes into a separate branch at the time of release.
So everyone can contribute simply to the master and does not have to care if 
where to push depending if it is a bug-fix or a new development. The only  
thing to ensure is that the master branch compiles and runs after each commit.

Substantial changes have still should be done inside separate branches, like 
my start of refactoring some parts in the Rails 2.0 branch.
Stefan

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

I have pushed the Rails1.5.x branch and the Rails 1.5.1 tag to the repo.

On Monday, October 10, 2011 08:04:03 pm brett lentz wrote:
> It's far more important to me that each release is accessible from the
> repo. How it achieves that is totally negotiable.
> 
> Personally, because you and Erik are far more active in the project
> than I am, I'm willing to give your preferences a bit more weight than
> mine. ;-)
> 
> IMO, it's easier to leave master as the lineage of stable changes and
> do any new development in (usually local) branches that can be merged
> into the stable trunk when they're ready.
> 
> In git, branches and tags are both very very cheap (and fast), unlike
> SVN. So, if you want to have all development happen in master, then
> branch off for stable releases, we can do that too.
> 
> 
> ---Brett

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

I looked at creating a JNLP several years ago, but couldn't really
make heads or tails of the process.

If you can make it happen, that'd be awesome. I'd love to have a link
on the website that people can click on to launch the latest version
of Rails.

---Brett.



On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> Erik:
> you are right 1.5.1+ is correct, my train of thought got sidetracked.
>
> I was thinking about that too, as changing the version number is the only
> remaining manual task to publish a new release.
>
> However there will always the need to update the wiki and html pages, so it
> still requires manually intervention.
>
> I am considering adding webstart support (in addition to the file releases -
> not as an replacement), but I want like to know the opinions of the others
> about that?
>
> Stefan
>
>
>>
>> I have no opinion on whether or not to put branches in the repo, as I
>> ignore them all (so far). However, I would like to see a correct (if
>> temporary) version number in the master Game.xml, so that the approximate
>> version of saved files can be identified. In my opinion that should be
>> 1.5.1+, literally: 1.5.1 and more.
>> (A build number would be even better, once we have managed nightly or
>> weekly builds. Would it be possible to have the code retrieve the latest
>> commit hash?)
>>
>> Erik.
>>
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

[Stefan F. <ste...@we...>]

Do you remember what the main obstacle was? I suspect the 
custom made classloader?

On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
> I looked at creating a JNLP several years ago, but couldn't really
> make heads or tails of the process.
> 
> If you can make it happen, that'd be awesome. I'd love to have a link
> on the website that people can click on to launch the latest version
> of Rails.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> > Erik:
> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
> > 
> > I was thinking about that too, as changing the version number is the only
> > remaining manual task to publish a new release.
> > 
> > However there will always the need to update the wiki and html pages, so
> > it still requires manually intervention.
> > 
> > I am considering adding webstart support (in addition to the file
> > releases - not as an replacement), but I want like to know the opinions
> > of the others about that?
> > 
> > Stefan
> > 
> >> I have no opinion on whether or not to put branches in the repo, as I
> >> ignore them all (so far). However, I would like to see a correct (if
> >> temporary) version number in the master Game.xml, so that the
> >> approximate version of saved files can be identified. In my opinion
> >> that should be 1.5.1+, literally: 1.5.1 and more.
> >> (A build number would be even better, once we have managed nightly or
> >> weekly builds. Would it be possible to have the code retrieve the latest
> >> commit hash?)
> >> 
> >> Erik.
> >> 
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

I suspect it was my own lack of knowledge on the whole process.

Our classloader (and hex drawing code) comes from the Colossus project
( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
doubt there's any technical blockers to providing one.

---Brett.



On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
> Do you remember what the main obstacle was? I suspect the
> custom made classloader?
>
> On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
>> I looked at creating a JNLP several years ago, but couldn't really
>> make heads or tails of the process.
>>
>> If you can make it happen, that'd be awesome. I'd love to have a link
>> on the website that people can click on to launch the latest version
>> of Rails.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
>> > Erik:
>> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
>> >
>> > I was thinking about that too, as changing the version number is the only
>> > remaining manual task to publish a new release.
>> >
>> > However there will always the need to update the wiki and html pages, so
>> > it still requires manually intervention.
>> >
>> > I am considering adding webstart support (in addition to the file
>> > releases - not as an replacement), but I want like to know the opinions
>> > of the others about that?
>> >
>> > Stefan
>> >
>> >> I have no opinion on whether or not to put branches in the repo, as I
>> >> ignore them all (so far). However, I would like to see a correct (if
>> >> temporary) version number in the master Game.xml, so that the
>> >> approximate version of saved files can be identified. In my opinion
>> >> that should be 1.5.1+, literally: 1.5.1 and more.
>> >> (A build number would be even better, once we have managed nightly or
>> >> weekly builds. Would it be possible to have the code retrieve the latest
>> >> commit hash?)
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------
>> >> --- --- All the data continuously generated in your IT infrastructure
>> >> contains a definitive record of customers, application performance,
>> >> security threats, fraudulent activity and more. Splunk takes this data
>> >> and makes sense of it. Business sense. IT sense. Common sense.
>> >> http://p.sf.net/sfu/splunk-d2dcopy1
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity and more. Splunk takes this data
>> > and makes sense of it. Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Java webstart (was: Rails 1.5.1 available)

[Stefan F. <ste...@we...>]

Brett:
I had a first look into adding Java Webstart support for Rails and as 
suspected there is an issue with the Classloader. Even if we provide a user 
defined classloader it is not used in those cases where Rails uses the 
Class.forName method to create new (18xx-game specific classes). This has to 
replaced.

Reference:
http://download.oracle.com/javase/1,5.0/docs/guide/javaws/developersguide/faq.html#211

In addition we have to make sure that all other resource files also get loaded 
by the classloader from the jar.

Except from that it is mainly an issue to write the ant-tasks for packaging a 
jar for Rails only and then upload this and the library jars (after signing 
them) to sourceforge. This can heavily automated by creating an ant task.

As it still requires some code/build modifications I prefer to add that to the 
to-do list for Rails 2.0 and have no intention to backport this to Rails 1.x.

Stefan


On Monday, October 10, 2011 09:02:04 pm brett lentz wrote:
> I suspect it was my own lack of knowledge on the whole process.
> 
> Our classloader (and hex drawing code) comes from the Colossus project
> ( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
> doubt there's any technical blockers to providing one.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
> > Do you remember what the main obstacle was? I suspect the
> > custom made classloader?
> > 
> > On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
> >> I looked at creating a JNLP several years ago, but couldn't really
> >> make heads or tails of the process.
> >> 
> >> If you can make it happen, that'd be awesome. I'd love to have a link
> >> on the website that people can click on to launch the latest version
> >> of Rails.
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> >> > Erik:
> >> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
> >> > 
> >> > I was thinking about that too, as changing the version number is the
> >> > only remaining manual task to publish a new release.
> >> > 
> >> > However there will always the need to update the wiki and html pages,
> >> > so it still requires manually intervention.
> >> > 
> >> > I am considering adding webstart support (in addition to the file
> >> > releases - not as an replacement), but I want like to know the
> >> > opinions of the others about that?
> >> > 
> >> > Stefan
> >> > 
> >> >> I have no opinion on whether or not to put branches in the repo, as I
> >> >> ignore them all (so far). However, I would like to see a correct (if
> >> >> temporary) version number in the master Game.xml, so that the
> >> >> approximate version of saved files can be identified. In my opinion
> >> >> that should be 1.5.1+, literally: 1.5.1 and more.
> >> >> (A build number would be even better, once we have managed nightly or
> >> >> weekly builds. Would it be possible to have the code retrieve the
> >> >> latest commit hash?)
> >> >> 
> >> >> Erik.
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> --- --- --- All the data continuously generated in your IT
> >> >> infrastructure contains a definitive record of customers,
> >> >> application performance, security threats, fraudulent activity and
> >> >> more. Splunk takes this data and makes sense of it. Business sense.
> >> >> IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> > 
> >> > ----------------------------------------------------------------------
> >> > --- ----- All the data continuously generated in your IT
> >> > infrastructure contains a definitive record of customers, application
> >> > performance, security threats, fraudulent activity and more. Splunk
> >> > takes this data and makes sense of it. Business sense. IT sense.
> >> > Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Java webstart (was: Rails 1.5.1 available)

[brett l. <bre...@gm...>]

Okay. Sounds like a fair bit of work to do, but very worthwhile. :-)

---Brett.



On Wed, Oct 19, 2011 at 11:31 AM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I had a first look into adding Java Webstart support for Rails and as
> suspected there is an issue with the Classloader. Even if we provide a user
> defined classloader it is not used in those cases where Rails uses the
> Class.forName method to create new (18xx-game specific classes). This has to
> replaced.
>
> Reference:
> http://download.oracle.com/javase/1,5.0/docs/guide/javaws/developersguide/faq.html#211
>
> In addition we have to make sure that all other resource files also get loaded
> by the classloader from the jar.
>
> Except from that it is mainly an issue to write the ant-tasks for packaging a
> jar for Rails only and then upload this and the library jars (after signing
> them) to sourceforge. This can heavily automated by creating an ant task.
>
> As it still requires some code/build modifications I prefer to add that to the
> to-do list for Rails 2.0 and have no intention to backport this to Rails 1.x.
>
> Stefan
>
>
> On Monday, October 10, 2011 09:02:04 pm brett lentz wrote:
>> I suspect it was my own lack of knowledge on the whole process.
>>
>> Our classloader (and hex drawing code) comes from the Colossus project
>> ( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
>> doubt there's any technical blockers to providing one.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
>> > Do you remember what the main obstacle was? I suspect the
>> > custom made classloader?
>> >
>> > On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
>> >> I looked at creating a JNLP several years ago, but couldn't really
>> >> make heads or tails of the process.
>> >>
>> >> If you can make it happen, that'd be awesome. I'd love to have a link
>> >> on the website that people can click on to launch the latest version
>> >> of Rails.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
>> >> > Erik:
>> >> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
>> >> >
>> >> > I was thinking about that too, as changing the version number is the
>> >> > only remaining manual task to publish a new release.
>> >> >
>> >> > However there will always the need to update the wiki and html pages,
>> >> > so it still requires manually intervention.
>> >> >
>> >> > I am considering adding webstart support (in addition to the file
>> >> > releases - not as an replacement), but I want like to know the
>> >> > opinions of the others about that?
>> >> >
>> >> > Stefan
>> >> >
>> >> >> I have no opinion on whether or not to put branches in the repo, as I
>> >> >> ignore them all (so far). However, I would like to see a correct (if
>> >> >> temporary) version number in the master Game.xml, so that the
>> >> >> approximate version of saved files can be identified. In my opinion
>> >> >> that should be 1.5.1+, literally: 1.5.1 and more.
>> >> >> (A build number would be even better, once we have managed nightly or
>> >> >> weekly builds. Would it be possible to have the code retrieve the
>> >> >> latest commit hash?)
>> >> >>
>> >> >> Erik.
>> >> >>
>> >> >>
>> >> >>