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

Fri Jul 19 13:57:42 PDT 2013

I just ran into a build failure with LB 1.5-SNAPSHOT (trunk) due to a missing <version> coordinate in both the components and tool poms for the spring dependency.  The fix is trivial and outlined in the ticket below [1].

Anth

https://jira.sakaiproject.org/browse/LSNBLDR-269

On Jul 19, 2013, at 4:48 PM, John Bush wrote:

> 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. **
> _______________________________________________
> 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"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130719/8955aca4/attachment.html 