> Would prefer addon devs don't do this, some do already but it means we > can't be sure the addon in SVN is really the latest one, have to > contact devs before release to make sure we pull the latest version > in, and it won't be tested as much (or not and have older addons in > which miss features/fixes),
While I understand the inconvenience this can pose, there is already too much inconvenience for me the other way around. So for the time being, at least, I'm going to do primary development of Rigify on github (http://github.com/cessen/rigify), and merge stable changes during the appropriate BCon stages. If the development model for addons included with Blender changes at some point, I'll reconsider. But I don't think that model necessarily needs to change. I treat (and want to treat) Rigify as an independent project, and would really prefer a less centralized development model for it, and inclusion as an officially supported addon hinders both those things by design. So this seems like a decent compromise: it lets me develop it independently as needed/wanted, but it can still be included as an official addon for those who want it to be so. We can think of the github repo as something like a development branch. I would also be perfectly happy for Rigify to not be included as an official addon, but I think there may be others that would object to that. For example, there was a certain someone that argued in favor of its inclusion after Sintel. ;-) > users who want to test latest version need > to manually grab it. - just becomes a hassle IMHO, ...makes conflicts > more likely too. This is a use-case that should be better supported anyway, IMHO. Obviously if two conflicting versions of an addon are enabled simultaneously, we can't expect that to work. But simply having two different versions of an addon present... not sure why that needs be an issue. Consider, for example, someone having two different versions of an external renderer installed, and they want to be able to use either/or in different projects (maybe one is more stable, but the other has more features). I think there are meaningful use-cases outside of Rigify and the current situation. --Nathan On Sun, Feb 17, 2013 at 7:24 PM, Campbell Barton <[email protected]> wrote: > On Mon, Feb 18, 2013 at 4:58 AM, Nathan Vegdahl <[email protected]> wrote: >> Thanks for the fix Irie! >> >>> Anyway, I don't understand why you did such big changes in Bcon4... >> >> Fair enough. It seemed like the best option of bad options. I'm >> currently working with a studio to improve Rigify for their pipeline, >> but I have a limited amount of time to be on-site working with them. >> Given that Rigify is an addon, and not part of Blender proper, I felt >> it was worth it for the sake of properly documenting the changes and >> milestones instead of having a mega-commit at the end. >> >> There's also a complicating factor, which is that they're working with >> SVN blender, so every time they update, it wipes out any local Rigify >> changes. >> >> All-in-all, perhaps not the best choice on my part, but it wasn't on a whim. >> >> In any case, I'll avoid this in the future. Perhaps I ought to >> maintain a parallel git repo somewhere for publishing out-of-sync >> changes. > > Would prefer addon devs don't do this, some do already but it means we > can't be sure the addon in SVN is really the latest one, have to > contact devs before release to make sure we pull the latest version > in, and it won't be tested as much (or not and have older addons in > which miss features/fixes), users who want to test latest version need > to manually grab it. - just becomes a hassle IMHO, ...makes conflicts > more likely too. > > Best just try avoid this situation again, if an addon is well > maintained we shouldn't be finding its broken right before release. > > Of course if you wanted to make a git repo to work on some > improvements during the week of the release, then pull the changes > back into svn right after and continue development in SVN, thats > different. > >> --Nathan >> >> >> On Sat, Feb 16, 2013 at 7:51 PM, IRIE Shinsuke <[email protected]> >> wrote: >>> Hi Nathan, >>> >>> Your recent commit (r4286) introduced a bug in poll() of the new >>> "Rigify Dev Tools". It causes an error every time UI is updated: >>> >>> Traceback (most recent call last): >>> File >>> "/home/irie/build/blender2.6/cmake/bin/2.65/scripts/addons/rigify/ui.py", >>> line 206, in poll >>> return obj.mode == 'EDIT_ARMATURE' >>> NameError: global name 'obj' is not defined >>> >>> >>> The following patch fixes it: >>> >>> Index: release/scripts/addons/rigify/ui.py >>> =================================================================== >>> --- release/scripts/addons/rigify/ui.py (revision 4288) >>> +++ release/scripts/addons/rigify/ui.py (working copy) >>> @@ -203,7 +203,7 @@ >>> >>> @classmethod >>> def poll(cls, context): >>> - return obj.mode == 'EDIT_ARMATURE' >>> + return context.mode == 'EDIT_ARMATURE' >>> >>> def draw(self, context): >>> r = self.layout.row() >>> >>> >>> Anyway, I don't understand why you did such big changes in Bcon4... >>> >>> Thanks, >>> >>> -- >>> IRIE Shinsuke >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
