[Building Sakai] consider updating your copy of Lessons, particularly if you are running 2.9 before 2.9.3

[John Bush]

Just a heads up to anyone considering switching from 1.4 stuff to 1.5
(trunk) stuff of lesson builder.  The webapp and component names have
changed:

webapps/sakai-lessonbuilder-tool and
components/sakai-lessonbuilder-components

are now

webapps/lessonbuilder-tool and components/lessonbuilder-components

People are probably pretty used to cleaning things out of shared, but this
bit me.  In my dev env, I don't cleanout webapps and components as often.


On Wed, Jul 17, 2013 at 10:51 AM, John Bush <jbush at anisakai.com> wrote:

> Attached patch here:
> https://jira.sakaiproject.org/browse/LSNBLDR-268
>
> so you can avoid this manual change of code to set a cache expiration.
>
>
> On Wed, Jul 17, 2013 at 9:58 AM, Charles Hedrick <hedrick at rutgers.edu>wrote:
>
>>
>> On Jul 17, 2013, at 12:41 PM, John Bush <jbush at anisakai.com> wrote:
>>
>> I need some clarity here.  So what is in trunk is going to become 1.5 and
>> be officially tagged for 2.9.3.  Is that correct ?
>>
>>
>> Lessons trunk is 1.5. As I understand it, there's always a version
>> number. 2.9 is bound to 1.4.x. 2.10 will be bound to 1.5.  A separate
>> branch for 1.5.x will be created at the time trunk is branched for 2.10.
>> Lesson trunk will then become 1.6.
>>
>> I do most changes in parallel on 1.4.x and trunk (i.e. 1.5). The main
>> difference is a few major new features and design changes that are in trunk
>> only. But bug fixes are generally done to both, except if they deal with
>> things only present in trunk.
>>
>> The 2.9.x release process generates tags for 1.4.x. That wouldn't
>> normally affect trunk. However enough places are using trunk that I want to
>> do a QA'd "release" from trunk. So I'm going to do a tag like
>> lessons-1.5.x-2.9.3 from trunk at the same time that the release process
>> generates the 2.9.3 tag in 1.4.x. I assume it will be called lessons-1.4.3.
>> I'm not currently planning to tag trunk for all the beta and RC tags, but I
>> will if anyone wants it. I've already done a pre-2.9.3 tag for umich,
>> simply to document the version they're using for their fall deployment.
>>
>> We'll see what kind of changes happen to trunk after that release. I
>> might possibly do a 1.5.x branch and thus move to 1.6 in trunk before the
>> main 2.10 branch if it looks like changes are going beyond what should be
>> in 2.10. For the moment I don't see anything like that.
>>
>> Regarding the 1.4.x and this caching business.  If you aren't going to
>> make a tag until 2.9.3 RC is cut, can you post a diff on how to enable
>> caching, or otherwise point me towards where to figure out specifically
>> what change you are talking about.  Furthermore its seems like having to
>> change code for QA and then switch it before you move to PROD is a bad
>> practice, if I'm understanding you correctly.  Wouldn't it be better to
>> make caching configurable to avoid this.  Maybe once you point me where to
>> look at that I'll just fix it for you.
>>
>>
>> For the moment I've turned on caching in 1.4.x but not in trunk. That
>> lets people test either way (the code is the same otherwise), and means
>> that there won't be a change for 2.9.3 release.
>>
>>
>> On a lighter note, there is so much I want to say about what you are
>> going to do trunk, but I fear the PC cops would lock me up.
>>
>>
>> On Wed, Jul 10, 2013 at 5:41 PM, Hedrick Charles <hedrick at rutgers.edu>wrote:
>>
>>> Let's see if it's needed. To me it only makes sense to tag versions if
>>> there's been substantial QA for them, or you've fixed something that really
>>> matters, and there's nothing dangerous added at the same time.
>>>
>>> This is the first time for quite a while that I've really recommended
>>> trunk. It's partly because I know people have done a lot of the 2.9.3 QA in
>>> trunk, and Rutgers is doing internal QA on trunk as well. UMich has now
>>> tested the new inline Question code. It previously hadn't had any testing
>>> outside Rutgers, which made me nervous about generating a tag with it
>>> included.
>>>
>>> The reason the 1.4.x tags have made sense is that a lot more QA happens
>>> right before a release. Before Lessons was in the core I did them to
>>> document which versions Rutgers had deployed, and other milestones. But
>>> since 2.9.0 we've got the Sakai release process and associated testing. For
>>> the moment at least I feel more confident in it than in my own testing.
>>> (Rutgers production has not tracked trunk changes. It's an older copy of
>>> trunk that's very close to 1.4.x We're resync'ing this summer.) So I'm
>>> happy with 1.4.x tags being produced by the release process, and no trunk
>>> tags.
>>>
>>> I feel that enough QA is happening on trunk that it makes sense to start
>>> fagging it. That will start with 1.5-for-2.9.3. But I suspect there wont'
>>> be another QA effort until this fall when we start the 2.10 beta. The beta
>>> process and RC process will automatically generate Lessons tags in trunk.
>>> The only way I envision doing an intermediate tag is if Rutgers ends up
>>> deploying something significantly different from 1.5-for-2.9.3, or a
>>> significant bug turns up in production, so that I don't want people using
>>> that tag.
>>>
>>>
>>> On Jul 10, 2013, at 7:46:47 PM, Steve Swinsburg <
>>> steve.swinsburg at gmail.com> wrote:
>>>
>>> > With this volatility I think I'd like to see more tags being created
>>> as different pieces are completed. It's much easier and accurate to say
>>> don't use 1.4.5 than the 'current' branch. Is current the revision right
>>> now, or anything from a fortnight ago when these problems were detected?
>>> >
>>> > Thanks
>>> > Steve
>>> >
>>> > Sent from my iPhone
>>> >
>>> > On 10/07/2013, at 23:18, Hedrick Charles <hedrick at rutgers.edu> wrote:
>>> >
>>> >> Enough things are going on in Lessons that you may want to use the
>>> newest code for Fall. This code will be included with 2.9.3, so if you plan
>>> to use that you'll be OK.
>>> >>
>>> >> In particular, for 2.9 before 2.9.3, there are issues because of
>>> changes to the gradebook. If your users use "Don't Release Item Until All
>>> Prerequisites are Completed" it will cause tests and assignments not to
>>> show in the gradebook for certain students unless you use the newest
>>> Lessons. Lessons own gradebook items also will not show in 2.9.1 and 2.9.2,
>>> though this is being fixed for 2.9.3.
>>> >>
>>> >> The Lessons that come with 2.9.x (Lessons 1.4.x) and Lessons trunk
>>> are both being QA'ed. I will tag Lessons trunk at the same time as the
>>> 2.9.3 release is made so you can find the trunk version that corresponds to
>>> the 1.4.x version that comes with 2.9.3. Rutgers and Michigan plan to
>>> deploy trunk, so that's where our internal QA is focused. (Development on
>>> trunk will continue after that release, but the changes I currently have in
>>> mind are low-risk, so it should be safe to continue following trunk at
>>> least for a while.)
>>> >>
>>> >> Trunk and 1.4.x of Lessons are very similar. The same fixes are being
>>> done to both. The difference is that trunk has a few new features:
>>> >> * Inline questions
>>> >> * Rubrics for student content
>>> >> * A redo of the skin done at Michigan. They have alternate skins with
>>> more interesting appearance, as shown at the conference.
>>> >>
>>> >> Common Cartridge export (and various fixes to CC import) was checked
>>> into 1.4.x as well as trunk, as promised at the conference. If you took a
>>> preliminary version of it you'll want to update, as I've been making
>>> continuing improvements to both export and import. I believe export will
>>> now export all content that is exportable. Further work will focus on
>>> adapting items that are not directly representable within the CC
>>> specifications, i.e. types of quiz questions and Lessons items that aren't
>>> supported in the specifications.
>>> >>
>>> >> Please DO NOT RUN the current 1.4.x or trunk in production on 2.9.
>>> (It should be fine on 2.8, which doesn't use the new gradebook code.) To
>>> facilitate QA I have disabled caching in the gradebook interface. I'm
>>> concerned about the impact that on gradebook performance. I will enable
>>> caching for the last 2.9.3 RC (on both 1.4.x and trunk).
>>> >>
>>> >> Both 1.4.x and trunk of Lessons are being tested with Sakai 2.8,
>>> though I'd certainly rather see sites use 2.9. The build has been changed
>>> so that there is a fairly simple profile setting to match the version of
>>> Sakai you're using.
>>> >>
>>> >> The urgency for update applies mostly to sites planning to use 2.9.1
>>> or later.
>>> >>
>>> >> _______________________________________________
>>> >> sakai-dev mailing list
>>> >> sakai-dev at collab.sakaiproject.org
>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> >>
>>> >> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>>
>> ** This message is neither private nor confidential in fact the US
>> government is storing it in a warehouse located in Utah for future data
>> mining use cases should they arise. **
>>
>>
>>
>
>
> --
> John Bush
> 602-490-0470
>
> ** This message is neither private nor confidential in fact the US
> government is storing it in a warehouse located in Utah for future data
> mining use cases should they arise. **
>



-- 
John Bush
602-490-0470

** This message is neither private nor confidential in fact the US
government is storing it in a warehouse located in Utah for future data
mining use cases should they arise. **
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130719/a80c68ff/attachment.html