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

Wed Jul 17 10:51:49 PDT 2013

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. **
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130717/64324973/attachment.html 